Preguntas de entrevista para Desarrollador Blockchain

Respuesta modelo

El más representativo es el módulo de liquidación de una plataforma de pagos, desplegado en Arbitrum One y verificado en el explorador. Es un contrato de unas cuatrocientas líneas que gestiona depósitos, cálculo de comisiones y retiradas, con proxy UUPS por detrás para poder corregir errores sin migrar saldos. Yo escribí el diseño de almacenamiento, la lógica de comisiones y todo el conjunto de tests. La decisión de la que más aprendí fue renunciar a una optimización en ensamblador que ahorraba unos nueve mil gas: la auditoría la habría encarecido y la ganancia real por usuario en una L2 era de céntimos, así que preferí mantener el código legible. Lleva catorce meses en producción, ha procesado alrededor de 180.000 operaciones y hemos hecho cuatro actualizaciones con timelock, ninguna de emergencia.

Respuesta modelo

En un contrato de recompensas dejé una función de consulta que otro contrato usaba para calcular el valor de una participación, y no protegí ese camino durante una retirada parcial. No era una reentrada clásica, porque no había reenvío de fondos, sino una reentrada de solo lectura: mientras se ejecutaba la retirada, el estado interno estaba a medias y la consulta devolvía un valor demasiado alto. Lo encontró el auditor externo, no yo. Lo corregí extendiendo el bloqueo a las funciones de lectura críticas y publicando un valor calculado solo al final de la operación. Lo que cambió después no fue una línea de código, sino el proceso: desde entonces, cualquier función de consulta que otro protocolo pueda utilizar entra en el modelo de amenazas como superficie de ataque, y lo compruebo con un test de invariante que la interroga en mitad de cada operación.

Respuesta modelo

Con una rutina estrecha y bastante escéptica. A diario reviso los informes de incidentes y los análisis post mortem de protocolos atacados, que es la fuente que más rinde por minuto invertido. Cada semana leo las propuestas de mejora del ecosistema que afectan a lo que uso —cambios de coste de opcodes, almacenamiento transitorio, abstracción de cuentas— y descarto todo lo que sea una cadena nueva sin usuarios. Una vez al mes reproduzco un ataque conocido en un fork local, porque leer el análisis y ejecutar el exploit dejan recuerdos muy distintos, y participo de vez en cuando en auditorías públicas por competición. Del lado normativo sigo las publicaciones de la CNMV y del Banco de España y los comunicados del SEPBLAC, que es lo que acaba condicionando el trabajo real.

Respuesta modelo

MiCA es el Reglamento UE 2023/1114 y hoy es plenamente aplicable. Distingue tres categorías —fichas referenciadas a activos, fichas de dinero electrónico y el resto de criptoactivos— y regula tanto a quien emite como a quien presta servicios. En España la CNMV es la autoridad que autoriza y supervisa a los proveedores de servicios de criptoactivos, mientras que el Banco de España conserva competencias sobre los emisores de fichas de dinero electrónico y referenciadas a activos; el registro que este último llevaba desde la Ley 7/2021 quedó absorbido al terminar el periodo transitorio, que España acortó hasta diciembre de 2025. Como desarrollador me afecta en cosas muy concretas: segregación de los activos de los clientes respecto de los propios, custodia de claves con doble control y registro auditable, conservación de los registros de operaciones, un procedimiento de reclamaciones con trazabilidad y la regla de viaje del Reglamento UE 2023/1113 en cada transferencia. A eso se suma DORA para las entidades financieras, que impone requisitos de resiliencia y notificación de incidentes graves.

Respuesta modelo

Porque el tipo de ingeniería que me interesa es el que aguanta una auditoría y una inspección, no solo un lanzamiento. En un entorno supervisado hay presupuesto real para auditar, procedimientos de despliegue que nadie se salta por una fecha de marketing y una conversación permanente con Cumplimiento que, aunque frene, obliga a pensar antes de escribir. También hay una parte práctica: prefiero un contrato indefinido y un proyecto que siga existiendo dentro de tres años. Dicho esto, no idealizo ninguno de los dos lados: en un entorno regulado el riesgo es la lentitud y la tentación de sustituir la seguridad real por documentación, y eso también hay que combatirlo desde dentro.

Respuesta modelo

Con la comparación que entiende cualquier consejo de administración: es una prima de seguro sobre el importe que va a custodiar el contrato. Le diría que el código va a gestionar, pongamos, quince millones de euros, que una vez desplegado no se puede corregir en caliente sin un procedimiento de horas y que los ataques a contratos con fallos de este tipo se han llevado cantidades muy superiores a esa cifra. Luego le daría la parte que no es miedo: la auditoría es también un requisito de facto para que otras entidades se integren con nosotros y un argumento comercial ante clientes institucionales. Y terminaría con lo que no cubre, porque exagerar es contraproducente: una auditoría reduce el riesgo, no lo elimina, y por eso proponemos combinarla con un programa de recompensas por errores y con un límite temporal de fondos durante las primeras semanas.

Respuesta modelo

Trabajo con Foundry como herramienta principal porque los tests están escritos en Solidity, lo que elimina la traducción mental entre lenguajes, porque el fuzzing y los tests de invariantes vienen integrados y porque forge snapshot me da regresión de gas en cada cambio, que es la métrica que más vigilo. Mantengo Hardhat cuando el proyecto tiene una capa importante de TypeScript, guiones de despliegue complejos ya escritos o un equipo que viene de ese ecosistema: cambiar de herramienta a mitad de proyecto solo por preferencia personal es una mala decisión de ingeniería. En la práctica conviven bien y en dos proyectos he tenido ambas, con Foundry para los tests y Hardhat para el despliegue y la integración.

Una reentrada ocurre cuando un contrato llama al exterior y ese contrato externo vuelve a entrar antes de que el estado interno se haya actualizado. El patrón de comprobaciones, efectos e interacciones cubre el caso clásico, pero se queda corto en tres situaciones. La primera es la reentrada entre funciones distintas: si el atacante vuelve por otra función que comparte estado, el orden dentro de una sola función no le protege. La segunda es la reentrada de solo lectura, en la que el atacante no modifica nada sino que consulta un valor durante el instante en que el estado está a medias, algo especialmente peligroso cuando otro protocolo usa esa consulta como precio. La tercera son las devoluciones de llamada implícitas: los tokens con notificación al receptor y el aviso de recepción de un token no fungible convierten una transferencia aparentemente inocente en una llamada externa. Como defensa uso un bloqueo que cubra también las funciones de lectura críticas, evito llamadas externas dentro de bucles y desconfío de cualquier token cuyo comportamiento no controle. Un detalle que a veces se olvida: enviar ether con las funciones limitadas a 2.300 unidades de gas dejó de ser una defensa fiable cuando cambió el coste de la lectura de almacenamiento, así que la protección tiene que estar en la lógica, no en el límite de gas.

La primera es el empaquetado del almacenamiento: colocar varias variables pequeñas en un mismo slot de 32 bytes convierte dos escrituras en una y ahorra decenas de miles de gas. Cuesta legibilidad y obliga a documentar el diseño, porque un cambio de orden posterior en un contrato actualizable provoca una colisión. La segunda es cachear en memoria las lecturas de almacenamiento dentro de un bucle y usar calldata en lugar de memoria en los parámetros de funciones externas: es casi gratis en términos de riesgo y suele ser lo primero que hago. La tercera son los errores personalizados en lugar de las cadenas de texto en las comprobaciones, junto con constantes e inmutables para lo que no cambia: ahorra despliegue y ejecución y no complica nada. A partir de ahí entra el terreno peligroso: bloques sin comprobación de desbordamiento, mapas de bits para banderas y ensamblador. Ahí el coste ya no es legibilidad, es riesgo, porque se desactivan comprobaciones del compilador y el auditor tiene que revisar a mano. Mi criterio es que la mayor parte del ahorro real casi nunca está en el micro-ajuste, sino en la arquitectura: escribir menos veces en almacenamiento, agrupar operaciones por lotes y mover cálculos fuera de la cadena con una prueba que se verifique dentro.

El ataque típico usa un préstamo relámpago para desequilibrar durante un instante las reservas de un par en un creador de mercado automático, y aprovecha que el contrato víctima calcula el precio directamente sobre esas reservas en el mismo bloque. La primera regla es no usar nunca el precio instantáneo de un par como fuente de verdad. Yo combino una fuente externa de datos con un precio medio ponderado por tiempo con una ventana suficientemente amplia, y comparo ambos: si la desviación supera un umbral, la operación se rechaza en lugar de ejecutarse con el dato dudoso. Sobre la fuente externa hay que comprobar la antigüedad del dato y no fiarse de que siempre esté fresco, además de validar el número de decimales, que es origen de errores tontos y caros. Dos matices importantes: el precio medio por tiempo tampoco es inmune si la liquidez del par es baja o si un actor controla varios bloques seguidos, y en una L2 hay que consultar el indicador de disponibilidad del secuenciador, porque si estuvo caído los precios pueden estar congelados y el contrato aceptaría datos obsoletos como si fueran válidos.

Con call se ejecuta el código del contrato destino en su propio contexto: su almacenamiento, y el remitente pasa a ser el llamante. Con delegatecall se ejecuta el código ajeno sobre el almacenamiento del contrato que llama, conservando remitente y valor; es la base de los proxies y también de casi todos sus problemas. El primero es la colisión de almacenamiento entre el proxy y la implementación, que se resuelve usando ranuras deterministas fuera del espacio normal según el estándar de proxies. El segundo es que el constructor de la implementación no se ejecuta a través del proxy, de modo que hay que inicializar con una función protegida y, sobre todo, dejar inicializada también la propia implementación: dejar un contrato de implementación sin inicializar y con capacidad de autodestrucción fue exactamente la causa del bloqueo de fondos de un monedero múltiple muy conocido en 2017. El tercero es la autorización de la actualización: en el patrón donde la lógica de actualización vive en la implementación, olvidar la comprobación que autoriza el cambio significa que cualquiera puede sustituir el código. Y el cuarto es más humano que técnico: actualizar a una implementación que ya no incluye la función de actualización deja el contrato congelado para siempre. Por eso los cambios pasan por timelock y firma múltiple, y se ensayan antes en un fork.

Cambia el modelo de costes: se paga la ejecución en la L2 y además la publicación de datos en la L1, así que el tamaño de los datos de llamada importa mucho más que el número de operaciones; con la llegada de los blobs esa parte se abarató, pero sigue existiendo. Cambia también la semántica de algunas variables globales: el número de bloque y la marca de tiempo no significan lo mismo que en la red principal y usarlos para medir intervalos cortos es una fuente de errores. Hay que contar con el alias de direcciones en los mensajes que vienen desde la L1, con la ventana de disputa de siete días para las retiradas del puente y con el hecho de que el secuenciador es un punto centralizado que puede caerse o censurar, lo que obliga a conocer el mecanismo de inclusión forzosa. Añado dos detalles prácticos que dan muchos disgustos: comprobar qué opcodes admite la cadena antes de compilar con una versión de la máquina virtual demasiado reciente, y consultar el indicador de disponibilidad del secuenciador en cualquier contrato que dependa de precios externos.

Cuando los participantes son conocidos y están identificados, el activo que se registra no necesita un token nativo y hay datos que no pueden ser públicos. Es el caso típico de un consorcio de entidades que quiere una verdad compartida sobre avales, certificados de origen, trazabilidad de un lote o liquidación de un servicio. Fabric aporta identidades gestionadas por autoridades de certificación, canales para separar la información entre participantes, colecciones de datos privados para que un dato solo lo vean quienes deben verlo y finalidad determinista, sin bifurcaciones ni esperas probabilísticas. Hay además una razón jurídica de peso en Europa: con datos personales, la inmutabilidad choca de frente con el derecho de supresión del reglamento de protección de datos, y una red permisionada donde el dato personal vive fuera de la cadena y dentro solo queda una prueba criptográfica es mucho más defendible. En España, además, existe la red del consorcio Alastria como opción de infraestructura ya montada. La contrapartida es que se renuncia a la ausencia de confianza y a la componibilidad: si el modelo de negocio necesita que cualquiera pueda integrarse sin permiso, Fabric es la elección equivocada.

Empiezo por tests unitarios sobre cada función, incluidos los casos de fallo, porque comprobar que algo revierte con el error correcto es tan importante como que funcione. Después escribo tests contra un fork de la red real para probar la integración con los protocolos y tokens que voy a usar de verdad, con sus rarezas: tokens que no devuelven valor booleano, tokens con comisión en la transferencia o con distinto número de decimales. Encima añado fuzzing, que genera entradas aleatorias para una propiedad concreta, y por último los tests de invariante, que son los que más fallos me han encontrado: se define lo que debe cumplirse siempre —la suma de los saldos nunca supera el total custodiado, nadie puede retirar más de lo que aportó— y se deja que la herramienta ejecute miles de secuencias de acciones aleatorias buscando romperlo. Sobre eso paso análisis estático como primer filtro y, en la lógica más crítica, verificación simbólica. La cobertura la trato como un suelo, no como un objetivo: un 100 % de líneas ejecutadas con aserciones débiles no demuestra nada.

Firmar a ciegas es hoy uno de los vectores más rentables para un atacante, así que sigo una lista fija. Primero verifico la dirección de la implementación nueva y que su código publicado se corresponde con el compilado desde el repositorio, reproduciendo la compilación yo mismo. Segundo, simulo la transacción en un fork o en un simulador y reviso los cambios de estado que produce, no solo que no revierta. Tercero, calculo el hash de la transacción del monedero múltiple de forma independiente y compruebo que coincide exactamente con el que muestra la pantalla del dispositivo físico, porque la interfaz web puede estar comprometida y mostrar una cosa distinta de la que se firma. Cuarto, confirmo identificador de cadena, nonce y destinatario. Y quinto, exijo que otro firmante haya hecho el mismo proceso por separado: si dos personas revisan mirando la misma pantalla, en realidad solo hay una revisión.

Lo primero es no publicar nada y no crear un aviso en el repositorio: cualquier señal pública es un mapa para el atacante. Después evalúo si el fallo es explotable ahora mismo y con qué coste. Si lo es, activo el mecanismo de pausa si existe y reúno las firmas necesarias; para eso hace falta tener localizados a los firmantes fuera del horario laboral, algo que se prepara antes y no esa noche. En paralelo aviso a la persona responsable de seguridad y abro un canal restringido con las tres o cuatro personas necesarias, ni una más. Si no hay pausa posible, la alternativa es un rescate ordenado de los fondos a una dirección segura, decidido con la dirección y con asesoría jurídica, nunca por iniciativa propia. Mientras se contiene, preparo la corrección y la someto a revisión externa aunque sea urgente. Y una parte que suele olvidarse: si la empresa es una entidad supervisada, hay obligaciones de notificación de incidentes graves a la autoridad competente y, si hay datos personales afectados, un plazo de 72 horas ante la Agencia Española de Protección de Datos; eso lo activa Cumplimiento, pero soy yo quien debe avisarles esa misma noche. Al cerrar, análisis posterior escrito y publicación cuando el parche esté desplegado.

Primero pregunto para qué sirve el token dentro del producto, porque en la mitad de los casos la respuesta honesta es que no hace falta y lo que se busca es financiación por otra vía. Si el token no aporta función, lo digo con esas palabras y propongo alternativas. Si sí la aporta, el contrato es la parte fácil y la menos crítica del calendario: lo que marca el ritmo es el análisis jurídico. Hay que determinar qué es el token, porque si funciona como un instrumento financiero no estamos en el ámbito de MiCA sino en el de la normativa del mercado de valores, con requisitos completamente distintos. Si entra en MiCA, hay obligaciones de documento informativo, de notificación a la autoridad competente y reglas estrictas sobre las comunicaciones publicitarias, además de las implicaciones fiscales y contables. Mi respuesta sería: puedo tener el contrato auditado en seis u ocho semanas, pero no lo desplegamos hasta que Asesoría Jurídica cierre la calificación, y me niego a lanzar sin auditoría externa por muy cerrada que esté la fecha de comunicación.

Le explico que precisamente la inmutabilidad es el problema: el reglamento europeo de protección de datos reconoce el derecho de supresión y de rectificación, y un registro que por diseño no se puede borrar entra en conflicto directo con ese derecho. Le propongo la arquitectura que sí funciona: los datos personales viven en una base de datos convencional, sujeta a las políticas de conservación y borrado habituales, y en la cadena solo se registra una prueba criptográfica que permita demostrar después que el documento no ha cambiado. Advierto de un matiz que muchos pasan por alto: un hash puede seguir siendo dato personal si permite reidentificar a la persona, especialmente cuando el conjunto de valores posibles es pequeño, así que hay que añadir un valor aleatorio de sal y guardarlo fuera. Si el caso exige más detalle en cadena, la vía es una red permisionada con colecciones de datos privados y no una cadena pública. Y cierro proponiendo que la decisión la valide la persona responsable de protección de datos por escrito, porque aquí el riesgo es sancionador y no técnico.

No lo planteo como una discusión de principios, sino de riesgo concreto. Lo primero es mirar qué se copia exactamente: si es una biblioteca estándar y ampliamente auditada, usarla es lo correcto y lo contrario sería el error. El problema aparece cuando se copia el contrato de un protocolo entero, porque se hereda su modelo de amenazas y sus supuestos, que casi nunca coinciden con los nuestros: otro token, otra fuente de precios, otra estructura de comisiones. Y se heredan sus fallos: la mayoría de los ataques a bifurcaciones de protocolos conocidos han explotado exactamente eso. Mi propuesta sería reducir el alcance de la versión inicial para llegar a la fecha con menos funciones bien revisadas, en lugar de llegar con todas mal revisadas. Si aun así se decide seguir adelante, dejo por escrito el riesgo en la revisión de código y pido un límite de fondos durante las primeras semanas.

Los ordeno por severidad y por explotabilidad real, que no siempre coinciden. Los críticos y los altos se corrigen sí o sí y se reverifican con el auditor, sin excepción. Los medios los examino uno a uno: algunos se corrigen, otros se mitigan con un parámetro operativo, por ejemplo un límite de importe, y otros se aceptan por escrito con firma de la persona responsable del producto. Los bajos y los informativos se documentan y entran en el plan de la siguiente versión. Después vuelvo a mirar el conjunto, porque catorce hallazgos suelen indicar un problema de diseño y no catorce descuidos, y si detecto un patrón lo pongo sobre la mesa aunque duela. Con esa información propondría un lanzamiento por fases: salimos en la fecha con un límite de fondos y una lista blanca durante dos semanas, y levantamos los límites cuando la reverificación esté cerrada. Lo que no negocio es desplegar con un hallazgo crítico abierto, y así lo diría en la reunión.