Análisis

Quién autoriza a una máquina a reescribirse

La especificación describe cómo un agente se compone código nuevo y cómo ese código entra en servicio. Miramos desde un ángulo: qué peligros aparecen y qué parte de la construcción responde por cada uno.

Por qué permitirlo siquiera

Un programa corriente no se cambia a sí mismo: su comportamiento lo fija quien lo escribió y solo varía con una nueva versión. Es fiable y, en la mayoría de los casos, correcto.

El argumento a favor de la automodificación es simple: un agente que funciona durante años se topa con tareas que no existían cuando se escribió. Actualizarlo a mano significa mantener a una persona en el bucle para siempre, que es justamente de lo que se quería salir.

Y aquí empieza lo interesante. En cuanto se le permite a una máquina reescribirse, surge una pregunta sin respuesta evidente: quién decide, y con qué fundamento, que la nueva versión es mejor que la anterior.

Tres amenazas, y son de distinta naturaleza

La especificación las enumera sin rodeos, y ese es uno de sus puntos fuertes. La primera es la introducción de defectos ocultos: código que parece funcional y lleva una puerta trasera.

La segunda es computacional. El código sintetizado puede contener recursión ineficiente o una fuga de memoria capaz de colgar al propio nodo que lo verifica. Aquí el ataque no va contra los datos sino contra el eslabón verificador.

La tercera se llama deriva de alineamiento y es bastante más desagradable que las dos anteriores. Cada mutación por separado parece inofensiva y supera la revisión. Pero paso a paso alejan el comportamiento de los límites éticos iniciales. Ningún paso concreto es una infracción; la infracción es su suma.

Es el mismo tipo de riesgo que la deriva epistémica en la memoria: nada se rompe, hay un desplazamiento lento que no se puede notar si se mira cada paso por separado.

El aislamiento: por qué precisamente WebAssembly

La primera línea de defensa es ejecutar el código nuevo aislado. Se eligió WebAssembly, y la elección se explica por dos propiedades: aislamiento estricto y determinismo.

Aquí la segunda importa más que la primera, aunque suele decirse al revés. Determinismo significa que el mismo código con los mismos datos da el mismo resultado a todo el que lo ejecute. Sin eso, la votación entre nodos sería imposible: cada uno obtendría su propia respuesta y no habría sobre qué ponerse de acuerdo.

El colgado se resuelve aparte: protección contra bucles infinitos y consumo desbocado. Sin ella bastaría una mala recursión para detener un nodo validador.

Cómo se mide que la nueva versión es mejor

Aquí la especificación hace lo que me parece su movimiento más honesto: introduce una función de aptitud explícita y la escribe como fórmula: `F(C) = w₁ · P(C) + w₂ · E(C) − w₃ · G(C)`.

El sentido es que «mejor» deja de ser una palabra y pasa a ser un número con sumandos nombrados: rendimiento, eficiencia y penalización. Ahora se puede discutir sobre los pesos, y esa es la discusión correcta, porque es concreta.

El punto débil se ve en el mismo sitio. Toda función objetivo premia exactamente lo que está escrito en ella, y un agente que la optimice hallará la manera de sumar puntos por una vía inesperada. La fórmula no elimina ese problema; lo vuelve discutible.

Prueba en lugar de confianza

Una mutación terminada no se acepta bajo palabra. El agente adjunta una prueba de conocimiento cero: la confirmación de que el código cumple las restricciones dadas sin revelar el código. Después viene la votación de los nodos del enjambre, y la versión aceptada se registra en un registro de código genético en Solana.

El valor del registro no está en la palabra de moda sino en una propiedad que las actualizaciones corrientes no tienen: el historial de cambios es inmutable. Si un año después resulta que sí hubo deriva, puede consultarse qué mutación la inició y cuándo, y eso no depende de la buena voluntad de quien llevaba el registro.

Qué queda sin resolver

Primero: la votación protege de la falsificación por una minoría, pero no de un error compartido. Si todos los nodos dejan de ver por igual el problema en una mutación, la mayoría la aprobará.

Segundo, y es mi impresión principal del texto: las tres amenazas están cubiertas de forma muy desigual. La puerta trasera y el colgado son problemas técnicos con soluciones articuladas: aislamiento, límites, prueba. La deriva de alineamiento es de otro orden y no puede cerrarse revisando un paso aislado, porque cada paso aislado es honesto.

La especificación lo reconoce al señalar que los invariantes éticos iniciales los fija el Arquitecto. Es decir, el punto de referencia queda fuera de la propia evolución y sigue siendo humano. Mientras sea así, la deriva al menos tiene contra qué medirse.

Fuente original

El artículo completo recorre el modelo de amenazas al completo, la matemática de la función objetivo y de las restricciones ZK, las especificaciones de los programas en Solana, el diseño de la votación del enjambre y ejemplos de código.