> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/es/rome-zk-evm/trust-model.md). # Modelo de confianza Quién puede cambiar una cadena Rome ZK EVM en devnet y en qué deben confiar los depositantes y retirantes. Los programas compartidos v0.3.0 en la red de desarrollo de Solana son actualizables. Una raíz probada es final según las reglas que esos programas hacen cumplir cuando se publica. Los operadores y usuarios también deben tener en cuenta quién puede cambiar esas reglas, quién controla cada cadena y quién puede dejar de publicar datos. Lea el [modelo de confianza completo de la red de desarrollo v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) para conocer los poderes exactos de cada autoridad y las comprobaciones en los programas actuales. ## Las autoridades del programa y del registro de Rome Rome posee la autoridad de actualización para los programas compartidos de bandeja de entrada, liquidación, Veritas y puente. Es una autoridad de firma única en la red de desarrollo. Una actualización puede entrar en vigor sin período de aviso y puede cambiar cualquier regla actual del programa. Trate esto como un supuesto de confianza de la red de desarrollo al depositar fondos. Rome también posee la autoridad del registro de liquidación. Según los programas actuales, puede activar o desactivar el registro sin permisos, cambiar los depósitos de registro para nuevas cadenas, cambiar las comisiones de liquidación incluso para una cadena existente sin un límite del protocolo, elegir el tesoro, cambiar la deriva permitida de las marcas de tiempo y cambiar la ventana global de recuperación. La ventana de recuperación puede acortarse para las cadenas registradas, pero no por debajo de 216.000 slots según el programa actual. La autoridad del registro registra, retira y cambia el slot de activación de las claves de verificación de una cadena. Una prueba solo cuenta frente a una clave activa para esa cadena. Por lo tanto, esta autoridad puede cambiar qué pruebas del invitado pueden finalizar nuevas raíces o dejar una cadena sin una clave utilizable. Una nueva entrada puede estar activa tan pronto como su transacción de registro llegue. Las raíces ya finalizadas siguen siendo finales cuando se retira una clave. Sin actualizar los programas, las claves de Rome no pueden crear una bóveda para una cadena cuya autoridad no posee Rome, cambiar el mint de esa bóveda, elegir a dónde van sus pagos ni retirar fondos de ella sin una salida probada. La autoridad de actualización del programa puede cambiar esas reglas, por lo que los usuarios deben confiar en que Rome no hará una actualización de ese tipo en la red de desarrollo. ## La autoridad de su cadena En la `./rollup` configuración, el pagador de Solana también es la autoridad de la cadena. Firma la publicación y finalización de lotes de la bandeja de entrada, la publicación de raíces probadas y la configuración de la cadena. Puede cerrar cuentas elegibles de lotes, fragmentos y raíces pendientes para recuperar su renta. No existe ninguna instrucción para cambiar esta autoridad, por lo que perderla detiene esas acciones firmadas. El registro fija el ID de la cadena, el génesis, el programa de la bandeja de entrada y la longitud de la ventana de desafío. La autoridad no puede editar el génesis registrado. Elige un destinatario de comisiones en ese génesis. Una cadena nueva normalmente empieza con saldos cero; cualquier saldo inicial declarado necesita un respaldo de bóveda correspondiente antes de que Rome registre su clave de verificación. La liquidación no comprueba por sí misma ese respaldo. La autoridad puede proponer un portal de salida, programa de puente, límite de retiro y fianza del publicador diferentes. Una propuesta entra en vigor no antes de una ventana de desafío de una cadena después. Cualquiera puede activarla después de ese slot. Los usuarios deberían inspeccionar la configuración de salida activa antes de retirar. Después del primer lote probado, la autoridad puede crear una cola de depósitos y elegir su plazo de inclusión, límites por lote y por bloque, depósito mínimo, comisión y destinatario de la comisión. Los cambios también tienen un slot de activación diferido. El programa actual restringe qué depósitos en espera puede un **finalizado** lote puede omitir. ## Lo que un usuario asume Un depositante confía en que el operador mantenga el secuenciador en funcionamiento, incluya el crédito en cola en un lote, publique el lote y pruebe su raíz. El operador puede elegir el orden de las transacciones EVM y rechazar transacciones; no existe un carril general de inclusión forzada para las transacciones EVM. Un saldo de depósito puede aparecer en la RPC de la cadena antes de que su raíz sea final en Solana. Un retirante necesita una raíz final que cubra el mensaje de salida, una configuración de salida activa y suficiente SOL envuelto en la bóveda de la cadena. El operador puede retrasar esa raíz deteniendo lotes o pruebas. Puede retrasar los pagos deteniendo el probador de salidas o dejando sin fondos la bóveda o el pagador de salidas. Cualquiera puede enviar una prueba de salida válida y ejecutar la liberación, por lo que el probador de salidas del operador no es la única vía una vez que los datos y la raíz final están disponibles. Según los programas actuales, la liquidación vincula una prueba de salida al portal configurado y a una raíz final. Limita las salidas por ventana de desafío e impide la repetición. El puente lee el destinatario del registro probado y comprueba la cuenta de tokens asociada del destinatario. Quien envía la liberación no puede redirigir su pago. Una bóveda sin fondos suficientes no puede pagar, aunque la prueba de salida sea válida. El depósito de registro de 5 SOL es una fianza de registro de cadena, no un respaldo para los saldos de los usuarios. Se vuelve reembolsable a la autoridad de la cadena después de la primera raíz final o de diez raíces publicadas. Si no se publica ninguna raíz antes de que termine la ventana de recuperación, cualquiera puede reclamar la cadena y su depósito no reembolsado va al tesoro. La ventana de la red de desarrollo en v0.3.0 es de 6.480.000 slots, unos 30 días, medidos desde el registro. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/es/rome-zk-evm/trust-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.