#nil $NIL @Nillion
Los Covenants de Nillion plantean una interesante cuestión de confianza: ¿qué establece que debe hacerse pública una instrucción privada?
Nillion describe su arquitectura de esta manera: un Covenant sella una carga útil sujeta a una condición. Sus fragmentos cifrados se distribuyen entre un comité de nodos, de modo que ningún operador puede reconstruir por sí solo 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 sujeta a una condición— y las garantías de seguridad más amplias, que dependen de la implementación y de los supuestos del protocolo.
Consideremos una operación condicional vinculada a una fuente de precios. Si esa fuente se retrasa o es inexacta, mantener la instrucción cifrada no hace que los datos que activan la operación sean fiables. 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 que sustentan la activación y la revelación importan tanto 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 sea viable en la práctica, ¿qué merece un mayor escrutinio: la fiabilidad de la condición que activa la operación, la integridad de la revelación o los supuestos en los que se basa el protocolo para proteger ambas?
$NIL
Los Covenants de Nillion plantean una interesante cuestión de confianza: ¿qué establece que debe hacerse pública una instrucción privada?
Nillion describe su arquitectura de esta manera: un Covenant sella una carga útil sujeta a una condición. Sus fragmentos cifrados se distribuyen entre un comité de nodos, de modo que ningún operador puede reconstruir por sí solo 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 sujeta a una condición— y las garantías de seguridad más amplias, que dependen de la implementación y de los supuestos del protocolo.
Consideremos una operación condicional vinculada a una fuente de precios. Si esa fuente se retrasa o es inexacta, mantener la instrucción cifrada no hace que los datos que activan la operación sean fiables. 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 que sustentan la activación y la revelación importan tanto 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 sea viable en la práctica, ¿qué merece un mayor escrutinio: la fiabilidad de la condición que activa la operación, la integridad de la revelación o los supuestos en los que se basa el protocolo para proteger ambas?
$NIL