⛓️ Blockchain Learning Path GitHub

Clase 38 · Paso a producción y operación

Clase independiente 38 de 66 · Nivel: Avanzado-Producción · Fuente base: prácticas públicas de integración del sector financiero y documentación de los componentes citados

⬅️ Clase anterior · 📚 Índice de las 66 clases · 🗂️ Mapa del tema · ➡️ Clase siguiente

Punto de partida

Pregunta guía: ¿Qué debe estar listo antes de que una transacción tenga consecuencias reales?

Caso que abre la clase: Un contrato probado se despliega sin propietario operativo del incidente.

Tecnología, operaciones, seguridad, legal y soporte deben presentar evidencia antes del go-live. Un contrato correcto no compensa la ausencia de propietario del servicio.

Gráfico pedagógico

Recorre el gráfico en voz alta: identifica supuestos, transformaciones y el punto exacto donde aparece evidencia.

flowchart TD
  C["Caso observado"] --> O{"¿Qué sabemos?"}
  O --> A["entornos, despliegue y rollback"]
  O --> B["seguridad, legal y soporte"]
  A --> P["Probar: SLA, costos y gobierno de cambios"]
  B --> P
  P --> L["Conclusión con límites"]

Fundamentos que sostienen la respuesta

  1. entornos, despliegue y rollback. En esta clase delimita qué objeto o relación estamos observando antes de sacar conclusiones. Localízalo explícitamente en «Un contrato probado se despliega sin propietario operativo del incidente.» y anota qué dato faltaría para refutar tu lectura.
  2. seguridad, legal y soporte. En esta clase explica el mecanismo que conecta la situación inicial con el cambio observable. Localízalo explícitamente en «Un contrato probado se despliega sin propietario operativo del incidente.» y anota qué dato faltaría para refutar tu lectura.
  3. SLA, costos y gobierno de cambios. En esta clase permite contrastar el resultado y formular el límite de la evidencia. Localízalo explícitamente en «Un contrato probado se despliega sin propietario operativo del incidente.» y anota qué dato faltaría para refutar tu lectura.

Una operación real, paso a paso, y dónde se rompe cada una

La lista de comprobación dice "usa un middleware". Aquí se ve qué pasa exactamente si no lo usas, siguiendo una operación de negocio corriente: un cliente solicita el rescate de 10 000 unidades de un fondo tokenizado.

sequenceDiagram
    participant N as Sistema de negocio
    participant M as Middleware
    participant F as Servicio de firma
    participant C as Cadena
    participant I as Indexador
    participant L as Base de lectura
    N->>M: solicitud de rescate (id interno)
    M->>M: reglas de negocio y cumplimiento
    M->>C: eth_call (simulación)
    C-->>M: resultado previsto
    M->>F: pedir firma (política M-de-N)
    F-->>M: transacción firmada
    M->>C: enviar
    C-->>I: evento Rescate
    I->>L: proyectar estado
    L-->>N: la pantalla ya lo muestra

Y ahora el mismo recorrido, con lo que falla al saltarse cada paso:

Paso Qué aporta Si te lo saltas
Reglas antes de firmar Aplica límites, listas y horarios en un solo sitio La regla acaba duplicada en cada pantalla que puede iniciar la operación, y basta olvidarla en una para que se escape
Simulación (eth_call) Predice el resultado sin gastar Se firman transacciones que revierten: se paga el gas, no hay efecto, y el usuario ve un cobro sin resultado
Cola de transacciones Desacopla el negocio de la red Si el gas se dispara o el RPC cae, la petición del cliente falla en su cara en vez de esperar y reintentar
Servicio de firma con política Ninguna persona sola mueve fondos La clave acaba en una variable de entorno de un servidor, y quien acceda a ese servidor es dueño del fondo
Indexador + base de lectura Las pantallas leen a velocidad de base de datos Cada clic dispara un eth_call; la interfaz va lenta y se cae entera cuando cae el proveedor RPC
Idempotencia por id interno La misma solicitud no se ejecuta dos veces Un reintento tras un timeout ejecuta el rescate dos veces. La cadena no tiene forma de saber que era el mismo

El último es el más caro y el menos citado. En un sistema clásico, un doble apunte se corrige con un asiento inverso. Aquí, la segunda transferencia es tan válida y tan definitiva como la primera: la corrección exige que la contraparte colabore.

💡 En una frase: el middleware no es una capa de arquitectura por elegancia — es el sitio donde se decide, se simula y se registra una sola vez lo que en la cadena no se puede deshacer.

Trabajo práctico

Método propio: readiness review multidisciplinario.

Actividad: Ejecutar un readiness review multidisciplinario.

Trabaja en entorno local, regtest, signet o testnet según corresponda. Conserva entradas, comandos, salidas y bloque o instante de corte. Una captura aislada no demuestra reproducibilidad.

Errores que esta clase corrige

Vuelve al caso inicial, elige el error más peligroso y describe una comprobación concreta que lo detectaría.

Demostración de aprendizaje

Entregable: Checklist firmable con responsables, evidencias y riesgos aceptados.

Comprobación formativa: Nombra un bloqueo de producción que no pueda resolver el equipo de desarrollo solo.

Para aprobar debes conectar el hecho observado con el concepto correcto, descartar al menos una interpretación alternativa y redactar una conclusión cuyo alcance no exceda la prueba.

Fuentes para comprobar y ampliar

Consulta además la bibliografía razonada, que declara procedencia y uso.

Cierre de la clase

Responde otra vez la pregunta guía sin mirar notas. Si tu respuesta no menciona evidencia, supuesto y límite, todavía describe el tema pero no lo domina. Continúa solo cuando otra persona pueda reproducir tu entregable.