#nil $NIL @Nillion
Los Covenants de Nillion plantean una interesante cuestión de confianza: ¿qué determina que deba revelarse una instrucción privada?

Nillion describe así su arquitectura: un Covenant sella una carga útil hasta que se cumple una condición. Sus fragmentos cifrados se distribuyen entre un comité de nodos, de modo que ningún operador por sí solo puede reconstruir la carga útil original. Cuando se cumple la condición, los nodos publican sus fragmentos, lo que permite reconstruir y verificar la carga útil en Ethereum antes de que se ejecute la acción posterior.

La distinción clave está entre el mecanismo documentado —sellar una instrucción hasta que se cumpla una condición— y las garantías de seguridad más amplias, que dependen de la implementación y de los supuestos del protocolo.

Pensemos en una operación condicionada vinculada a una fuente de precios. Si esa fuente se retrasa o es inexacta, mantener la instrucción cifrada no vuelve fiables los datos que activan la operación. La confidencialidad protege la estrategia de una exposición prematura; por sí sola, no garantiza que la condición se evalúe correctamente. Por eso, los supuestos de confianza en torno a la activación y la revelación son tan importantes como el mecanismo de privacidad.

La cuestión de fondo es en qué debe confiar el sistema. Una condición correcta, una revelación legítima y la confidencialidad son requisitos distintos. Proteger la carga útil no demuestra automáticamente que la condición se haya evaluado correctamente ni que la revelación haya seguido las reglas previstas. Esas garantías dependen del diseño de verificación del protocolo y de sus supuestos.

Para que la ejecución condicionada llegue a ser práctica, ¿qué merece un mayor escrutinio: la fiabilidad de la condición de activación, la integridad de la revelación o los supuestos en los que se basa el protocolo para proteger ambas?