Ecuador — Cuenca
Artículos

Reversible por comité, inmutable por defecto

1 de octubre de 2026
Hoy mantengo dos modelos mentales de la palabra desplegar abiertos al mismo tiempo. De día trabajo dentro del Banco del Austro, donde un cambio a un sistema de producción atraviesa un ticket, un revisor, un entorno de staging, una aprobación y una ventana de release antes de que se le permita acercarse al dinero de un cliente. De noche —y durante años antes del banco— escribo Solidity y Rust para sistemas donde deploy significa transmitir bytecode a una red que lo ejecutará, byte por byte, para siempre, sin la aprobación de nadie y sin botón de deshacer. El cliché dice que los bancos son lentos y rigurosos y que el cripto es rápido e imprudente. Después de vivir en ambos, creo que el cliché tiene el riesgo exactamente al revés. En el banco, un deploy es el final de un pipeline largo y deliberadamente reversible: rama de feature, pull request, un gate de revisión que nadie puede saltarse, un entorno de staging, una aprobación de pruebas de aceptación, una ventana de cambio y un plan de rollback escrito antes de que el cambio salga. Todo está instrumentado para que el cambio se pueda deshacer. Una migración mala se revierte. Un asiento equivocado se corrige con un asiento de reversa. Un release roto se retira en la siguiente ventana. Toda la ceremonia existe para proteger un sistema en el que casi nada es verdaderamente final. On-chain, el pipeline suele ser tres personas en un grupo de Telegram — pero el artefacto es justo lo contrario. Una vez que un contrato está desplegado y hay valor dentro, el bytecode es inmutable y el ledger es solo-de-agregado. No hay rollback, no hay asiento de reversa, no hay hotfix silencioso a las 3am, a menos que hayas diseñado una ruta de actualización por adelantado: un patrón proxy, una clave de admin con timelock, un interruptor de pausa. Y cada una de esas salidas de emergencia es, en sí misma, una nueva superficie de ataque y un compromiso de centralización que luego tienes que justificar ante gente que eligió tu protocolo porque no tenía ninguna de las dos. La cultura informal despliega el artefacto más implacable con el que he trabajado. Un banco funciona sobre un ledger de partida doble, y el superpoder silencioso de la partida doble es que un error se corrige con otro asiento, nunca con un borrado. Suma los contracargos, las ventanas de disputa y la liquidación T+n, y tienes un sistema donde la mayoría de los errores tienen una ruta de recuperación medida en días. Por eso el banco puede permitirse tanto proceso: la ceremonia no compra finalidad, compra consistencia y una pista de auditoría. La lentitud es la prima de un sistema donde los errores son sobrevivibles. Un blockchain invierte la variable. La finalidad no es un riesgo a gestionar — la finalidad es el producto. Razonas sobre la profundidad de reorg y sobre finalidad probabilística frente a determinista precisamente porque, pasado cierto umbral de confirmaciones, el estado queda liquidado frente al mundo entero. Un exploit, por lo tanto, no es un ticket de bug; es una transferencia de valor permanente y adversarial. Así que el rigor que el banco vuelca en el proceso, un protocolo serio tiene que volcarlo en el código mismo: tests basados en propiedades, fuzzing de invariantes en Foundry, verificación formal de los caminos críticos, múltiples auditorías independientes, revisión de diseño de mecanismos de la economía, y un bug bounty que asume que el planeta entero está leyendo tu código fuente — porque lo está. El proceso del banco tiene responsables con nombre. Los requerimientos son documentos, los roles son formales, legal y cumplimiento están en el circuito, la revisión de seguridad es un gate, y la segregación de funciones significa que quien escribe un cambio no es quien lo aprueba ni quien lo libera. Cada decisión tiene un dueño responsable y una pista documental. El costo es la latencia: un cambio que técnicamente es un diff de dos líneas puede igual tardar semanas en coordinarse. On-chain, la coordinación es asíncrona, seudónima y meritocrática hasta el extremo. Un contribuyente central puede ser un handle con el que nunca has estado en una llamada. Las especificaciones viven en una página de Notion y un issue de GitHub; la gobernanza es un post en el foro y una votación con tokens. El throughput es genuinamente extraordinario — y la memoria institucional es aterradoramente frágil. Cuando el único contribuyente que tenía la matemática del vault en la cabeza se desconecta, el conocimiento se desconecta con él, y no hay runbook ni sucesor. Un banco defiende un perímetro con profundidad: redes privadas, WAFs, un SOC, pruebas de penetración programadas, controles PCI-DSS, y el supuesto de trabajo de que el atacante está afuera y los muros siempre se pueden subir más. El código es cerrado y, con razón o sin ella, parte del modelo se apoya en eso. On-chain no hay perímetro. El código es público, el mempool es público, el estado es público, y la recompensa por romperte está denominada directamente en dólares y se paga en el instante en que lo logras. Diseñas de forma adversarial desde la primera línea: guards de reentrancia, el orden checks-effects-interactions, resistencia a manipulación de oráculos, conciencia de MEV, y los chequeos de overflow que vienen gratis en Solidity ≥0.8 pero que igual razonas a mano. No hay un SOC al que llamar. La respuesta a incidentes es un hilo de Twitter a las 4am y una war room montando un rescate white-hat antes del siguiente bloque. El banco funciona sobre identidad verificada. KYC y AML significan que cada actor es conocido, regulado y responsable, y la confianza es en última instancia institucional — confías en el banco por lo que lo respalda. Un blockchain funciona sobre la ausencia deliberada de identidad confiable: el punto entero es que extraños que no pueden verificarse entre sí igual transaccionan, porque el consenso y el código hacen la verificación en su lugar. "El código es ley" suena a eslogan hasta que lo has visto aplicarse, literalmente y sin apelación, contra los ahorros de alguien. Del banco aprendí que el proceso no es burocracia por la burocracia. La gestión de cambios, las pistas de auditoría, la segregación de funciones y una aburrida ventana de release son cómo operas un sistema del que dependen miles de personas sin apoyarte en heroísmos. Antes leía toda esa ceremonia como pura fricción. Ahora leo la mayor parte como lecciones duramente ganadas que alguien codificó para no tener que reaprenderlas por las malas. Del blockchain aprendí que nada afila a un ingeniero como la irreversibilidad y un adversario público. Escribir código que no puedes parchar, para un sistema cuyo entorno de pruebas es un planeta hostil con una recompensa por tu cabeza, te vuelve más cuidadoso de lo que cualquier cantidad de proceso podría lograr. La síntesis honesta es que ninguna de las dos culturas es la terminada. El banco tiene el rigor pero trata la finalidad como algo que hay que esquivar; el cripto abrazó la finalidad pero todavía está inventando el rigor para merecerla. Sospecho que la próxima década de ambos se parece a una convergencia — bancos adoptando las garantías deterministas y criptográficamente demostrables que las cadenas dan por sentadas, y protocolos serios redescubriendo en voz baja por qué existen los comités de cambios. Resulta que tengo un pie en cada lado. La mayoría de los días no se siente como dos trabajos, sino como ver la misma pregunta —cómo confían los extraños un sistema con su dinero— respondida desde los extremos opuestos.