Que se haya llamado a init durante el despliegue no significa que desde entonces haya perdido sus permisos. La referencia de DuskVM lo deja claro: init sigue siendo una entrada exportada después del despliegue. Este detalle traslada la inicialización de una sola vez desde la garantía de la plataforma de vuelta al control de acceso del propio contrato. Si el código no deja un bloqueo de estado, el tiempo de despliegue es solo una experiencia, no un sello permanente.
Yo divido la responsabilidad en dos columnas. La plataforma se encarga de crear el estado inicial y, durante el despliegue, llamar a pub fn init según los parámetros. @Dusk El contrato mismo se encarga de registrar si ya se ha inicializado, rechazar ejecuciones repetidas en llamadas posteriores y también verificar si el caller tiene permisos. La primera columna garantiza que la función se llame; la segunda garantiza quién puede volver a llamarla y cuántas veces. Las dos columnas no pueden firmar una por la otra.
El riesgo no está en el nombre init, sino en qué puede escribir. La dirección del administrador, el mapeo de activos, los parámetros de tarifas o la dirección de un contrato externo: si se permite sobrescribirlos por segunda vez, las condiciones de confianza formadas en el primer despliegue se resetearán. Aquí no se puede inferir una vulnerabilidad solo por el nombre de la función; los hechos mandan. Solo cuando el código concreto carece de un bit de estado o de verificación del llamador, la inicialización repetida se convierte en una superficie de ataque real.
$DUSK Para ver la configuración inicial de un contrato, yo buscaría tres pruebas. ¿Existe en el estado persistente una marca initialized? ¿Falla explícitamente la segunda llamada? ¿Se verifica al caller antes de modificar los campos clave? La transacción de despliegue solo puede responder que se ejecutó en ese momento; no puede responder quién podrá ejecutarla después. Si una auditoría solo captura el recibo exitoso de la primera vez, la cuestión de permisos seguirá medio vacía.
Esta tabla de dos columnas también ofrece un juicio útil para usuarios comunes. Si el proyecto dice que los parámetros ya quedaron bloqueados durante el despliegue, se puede preguntar si el bloqueo lo hizo la máquina virtual o el código del contrato. Lo primero no concuerda con la documentación; lo segundo debería dejar evidencias en el código fuente y en pruebas de llamadas repetidas. init es una entrada de despliegue, y también una entrada pública después del despliegue. Lo que realmente es de una sola vez no depende del orden temporal, sino del rechazo por estado y de la autorización del llamador. #dusk
Yo divido la responsabilidad en dos columnas. La plataforma se encarga de crear el estado inicial y, durante el despliegue, llamar a pub fn init según los parámetros. @Dusk El contrato mismo se encarga de registrar si ya se ha inicializado, rechazar ejecuciones repetidas en llamadas posteriores y también verificar si el caller tiene permisos. La primera columna garantiza que la función se llame; la segunda garantiza quién puede volver a llamarla y cuántas veces. Las dos columnas no pueden firmar una por la otra.
El riesgo no está en el nombre init, sino en qué puede escribir. La dirección del administrador, el mapeo de activos, los parámetros de tarifas o la dirección de un contrato externo: si se permite sobrescribirlos por segunda vez, las condiciones de confianza formadas en el primer despliegue se resetearán. Aquí no se puede inferir una vulnerabilidad solo por el nombre de la función; los hechos mandan. Solo cuando el código concreto carece de un bit de estado o de verificación del llamador, la inicialización repetida se convierte en una superficie de ataque real.
$DUSK Para ver la configuración inicial de un contrato, yo buscaría tres pruebas. ¿Existe en el estado persistente una marca initialized? ¿Falla explícitamente la segunda llamada? ¿Se verifica al caller antes de modificar los campos clave? La transacción de despliegue solo puede responder que se ejecutó en ese momento; no puede responder quién podrá ejecutarla después. Si una auditoría solo captura el recibo exitoso de la primera vez, la cuestión de permisos seguirá medio vacía.
Esta tabla de dos columnas también ofrece un juicio útil para usuarios comunes. Si el proyecto dice que los parámetros ya quedaron bloqueados durante el despliegue, se puede preguntar si el bloqueo lo hizo la máquina virtual o el código del contrato. Lo primero no concuerda con la documentación; lo segundo debería dejar evidencias en el código fuente y en pruebas de llamadas repetidas. init es una entrada de despliegue, y también una entrada pública después del despliegue. Lo que realmente es de una sola vez no depende del orden temporal, sino del rechazo por estado y de la autorización del llamador. #dusk