Esta es una traducción de la documentación de gobernanza de Arbitrum Foundation.

La gobernanza de Arbitrum tiene dos órganos principales:

• La DAO: representada por los holders del token $ARB, los cuales votan y/o delegan sus tokens para aprobar las propuestas.

• El Consejo de Seguridad: está compuesto por 12 miembros que manejan la multisign. Cuando hay un caso de emergencia, 9 de 12 miembros deben dar su aprobación para realizar las medidas necesarias para resolver rápidamente la situación. Por otro lado, para otro tipo de medidas como actualizaciones de rutina que pasan por alto a la DAO, solo es necesaria la aprobación de 7 de 12 miembros.

Puede leer más sobre estos órganos y sus competencias en la Constitución de Arbitrum DAO.

Invariantes

• Solo las propuestas aprobadas hechas a través del gobernador constitucional ( la DAO) o el Consejo de Seguridad pueden actualizar el sistema.

• Todas las propuestas, excepto las realizadas por un Consejo de Seguridad con 9/12 miembros, pasarán por 3 delays: L2 timelock, delay de retiro y L1 timelock. El Consejo de Seguridad con la aprobación de 9/12 miembros debería poder realizar una actualización sin demoras.

• Una vez que se ha aprobado una propuesta, siempre hay tiempo para que un usuario salga de cualquier activo que tenga en Arbitrum One o Arbitrum Nova antes de que se ejecute la propuesta.

• Una propuesta no puede ser cancelada o bloqueada, excepto por el Consejo de Seguridad.

• Una vez que se ha aprobado una propuesta, cualquiera puede garantizar su ejecución completa en todas las etapas.

Activos bajo el control de la Governance

La gobernanza es responsable de los siguientes activos:

• Treasury: una parte de los tokens asignados a la DAO.

• Contratos Arb One: estos contratos están implementados en la Ethereum Mainnet. La gobernanza tiene derechos de actualización sobre estos contratos.

• Contratos Arb Nova: estos contratos están implementados en la Ethereum Mainnet. La gobernanza tiene derechos de actualización sobre estos contratos.

• Parámetros de Arb One L2: todas las chains de Arbitrum tienen un "owner" que pueden establecer ciertos parámetros. Lea más aquí. La gobernanza tiene control sobre el owner de la chain.

• Parámetros de Arb Nova L2: igual que los parámetros de Arb One L2.

• Contratos de gobernanza: la gobernanza tiene la capacidad de actualizarse y modificarse a sí misma.

Tipos de propuestas

Governance tiene la capacidad de actualizar tanto Arbitrum One como Arbitrum Nova, lo que podría afectar a los usuarios de esas chains. Cualquier propuesta ejecutada por Arbitrum DAO pasa por una serie de etapas, cada una con diferentes delays de tiempo, lo que garantiza que cualquier usuario que no esté de acuerdo con una actualización tendrá la oportunidad de salir de la chain antes de que entre en vigencia.

La excepción a esto son las propuestas que se consideran no constitucionales . Este tipo de propuesta no debería afectar el comportamiento de la chain, o debería hacerlo de forma limitada y bien entendida. En un inicio, el único tipo de propuesta no constitucional es el gasto de fondos del treasury.

Para diferenciar entre estos dos tipos de propuestas, la gobernanza de Arbitrum utiliza dos contratos de gobernador. Uno constitucional que requiere al menos el 5% de todos los tokens votables para votar "a favor" y, además, que más tokens votables voten "a favor" que "en contra" para ser aprobado, y uno no constitucional que requiere al menos 3% de todas los tokens votables para votar "a favor" y que más tokens votables voten "a favor" que "en contra" para ser aprobado. La capacidad de actualizar los contratos de Arbitrum la tiene el gobernador del 5%, por lo que ninguna propuesta hecha desde el 3% puede provocar cambios en el código de un contrato, o parámetros de la chain del "owner".

Delay de propuestas

Todas las actividades de gobierno ocurren en Arbitrum One. Allí se realizan propuestas, así como delegaciones y votaciones. Una propuesta hecha al gobernador constitucional experimenta suficiente delay (o retraso) para garantizar que los usuarios puedan salir de forma segura de la chain antes de que se ejecute la propuesta, en caso de que la consideren maliciosa o no estén de acuerdo con los cambios. Los 3 delays son:

1. Arbitrum One timelock - 3 días de retraso. Después de aprobar, se entrega una propuesta a un timelock (bloqueo de tiempo) en Arbitrum One. El propósito de este retraso es permitir a los usuarios realizar retiros de la chain si así lo desean.

2. Delay de mensaje L2->L1 - ~1 semana. Todas las propuestas deben retirarse a L1 antes de ejecutarse (incluso si eventualmente se ejecutarán nuevamente en un L2). Esto garantiza que cualquier salida realizada por los usuarios en el retraso anterior se pueda procesar antes de que lo haga la actualización, ya que ambos pasan por este retraso.

3. Retraso de la Mainnet de Ethereum - 3 días. Los retiros se retrasan por cualquier desafío abierto en el rollup de Arbitrum One. Esto puede causar que muchos retiros sean elegibles para ejecución en L1 al mismo tiempo. Esto significa que aunque un usuario inició su retiro antes del mensaje de actualización L2->L1, ambos podrían volverse elegibles para la ejecución en L1 aproximadamente al mismo tiempo, lo que haría que los usuarios compitan en L1 contra la actualización. Para evitar esto, la propuesta de actualización pasa por un retraso adicional después de llegar a la L1, lo que garantiza que todos los retiros iniciados antes de la propuesta de actualización serán elegibles para su ejecución primero.

Una vez que la propuesta ha pasado por cada uno de estos retrasos, se dirige al objetivo de su ejecución, que podría estar en cualquiera de las mainnets de Arbitrum One, Nova o Ethereum. Cuando el objetivo está en una L2, la propuesta contendrá información para formar el mensaje L1->L2 correcto.

Token

Actualmente el token $ARB se encuentra implementado en 3 instancias, cada una en una red diferente: Arbitrum One, Arbitrum Nova y Ethereum Mainnet.

El supply total del token es monitoreado por la instancia de Arbitrum One del token, el supply total del token en otras redes no es representativo del supply total real. La instancia de Arbitrum One también permite el mint de hasta el 2% del supply total una vez al año.

Exclusión de votos

Los holders de tokens tienen la capacidad de excluir sus votos de los cálculos del quórum de gobierno delegando a una "dirección de exclusión" designada, dirección 0xA4b86. Delegar en la dirección de exclusión evita que los tokens que no se espera que participen en el gobierno inflen "artificialmente" el tamaño del quórum requerido. Por ejemplo, el treasury no debería utilizar sus propios tokens para votar propuestas, por lo que los votos de la treasury se delegan en la dirección de exclusión.

Visión general de los contratos de gobierno

Profundicemos un poco más en cada uno de los contratos individuales y describamos más específicamente el papel que juega cada uno en el sistema.

Gobernador Arbitrum One 3%

Corresponde al gobernador no constitucional. Las propuestas hechas requieren al menos el 3% de todos los tokens votables que voten "a favor" y que existan más tokens votables a "a favor" que en "en contra" para ser aprobadas. Actualmente solo tiene la potestad de gastar fondos en la tesorería.

Arbitrum One 5% Gobernador

Corresponde al gobernador constitucional , las propuestas hechas requieren al menos el 5% todos los tokens votables que voten "a favor" y que existan más tokens votables a "a favor" que en "en contra" para ser aprobadas.

Tabla de comparación

Arbitrum One L2 Timelock (Bloqueo de tiempo L2 de Arbitrum One)

Las propuestas pueden ser programadas aquí por el gobernador del 5%, o por un acuerdo 7 de 12 en el Consejo de Seguridad. Este bloqueo de tiempo impone un retraso de 3 días antes de que cualquiera pueda ejecutar la propuesta.

L1 Timelock (Bloqueo de tiempo L1)

Este timelock recibe propuestas que fueron ejecutadas en el Arb One L2 Timelock. Para que el Timelock L2 programe propuestas en el timelock L1, debe enviar un mensaje L2->L1. Al recibir este mensaje, el bloqueo de tiempo L1 comprueba que el remitente era el bloqueo de tiempo L2 en Arbitrum One, y solo permite que ese contrato programe propuestas. Este bloqueo de tiempo impone un retraso de 3 días antes de permitir que alguien lo ejecute.

Tabla de comparación

Ejecutor de update en L1

El ejecutor de update L1 es el propietario de los contratos relacionados con Arbitrum One y Nova que existen en la mainnet de Ethereum. Tiene los derechos para actualizar estos contratos, así como algunos poderes especiales de propiedad. Todas las actualizaciones a estos contratos deben ejecutarse a través del Ejecutor de update L1. Solo el Consejo de Seguridad y el L1 Timelock tienen los derechos para llamar al Upgrade Executor.

Ejecutor de update de Arbitrum One

El ejecutor de update de Arbitrum One es el "owner o propietario" de la chain de Arbitrum One, también tiene los derechos para cambiar la configuración y actualizar la gobernanza. Solo el Consejo de seguridad de Arbitrum One y el L1 Timelock (a través de un ticket que se puede volver a usar) tienen los derechos para ejecutar propuestas a través del Ejecutor de update de Arbitrum One.

Ejecutor de update de Arbitrum Nova

El ejecutor de update de Arbitrum Nova es el "owner o propietario" de la chain de Arbitrum Nova. Solo el Consejo de Seguridad de Arbitrum Nova y el L1 Timelock (a través de un ticket que se puede volver a usar) tienen los derechos para ejecutar propuestas a través del Ejecutor de update de Arb Nova.

Tabla de comparación

Constitución de Arbitrum DAO

El contrato de Constitución de Arbitrum DAO almacena el hash del texto canónico de la Constitución. Para actualizar la Constitución, se debe crear una propuesta que llame ArbitrumDAOConstitution.setConstitutionHashcon el nuevo contenido hash. El campo "descripción" de la propuesta debe decir:

Actualice el hash de la Constitución para que sea el hash keccak256 del siguiente texto: "... texto de la Constitución, etc..."

Si el hash keccak256 del nuevo texto de la Constitución no coincide con el hash proporcionado, la DAO debe rechazar la propuesta.

Configuración general

Al ponerlo todo junto, obtenemos una imagen de las conexiones entre todos los componentes y dónde residen en Arbitrum One, Nova y Ethereum Mainnet.

La ejecución de una propuesta aprobada requiere una serie de transacciones; cuando se requiere una nueva transacción, estos se representan con una figura de palitos. Los objetos redondos del diagrama anterior representan contratos que ya existen en el sistema Arbitrum. Estos no son introducidos por la gobernanza, sino que son utilizados por la gobernanza o son propiedad de la gobernanza.

Ciclo de vida de la propuesta

Los contratos en el diagrama codifican la propiedad de las chains asegurando que solo la gobernanza o el Consejo de Seguridad tengan los derechos para actualizar los contratos de Arbitrum. El camino que tomará la propuesta a través de estos contratos se define en la propia propuesta. A medida que la propuesta avanza por cada etapa de la ruta, se desenvuelve una capa de los datos de la propuesta; los datos desenvueltos definen qué contrato se debe llamar a continuación.

Esto significa que formar una propuesta implica trabajar hacia atrás desde el objetivo, envolviendo los datos varias veces para definir la ruta que tomará la actualización.

Puede obtener más información sobre cómo se codifica la ruta en el documento del ciclo de vida de la propuesta.

Cancelación de propuesta

Ambos contratos de gobernador tienen la posibilidad de cancelar propuestas programadas en el L2 Timelock. El Consejo de Seguridad también puede cancelar propuestas llamando a L2ArbitrumGovernor.relay. Tenga en cuenta que aunque el Consejo de Seguridad del gobernador central tiene la posibilidad de cancelar propuestas en el L2 Timelock llamando a la función “cancel” directamente, para mayor claridad y consistencia, debe usar el método “relay” mencionado anteriormente.

Futuras chains gobernadas por DAO

Cuando la DAO autoriza una nueva chain L2, se deben realizar los siguientes pasos para que la nueva chain pase a estar gobernada por la DAO:

1. Implemente un nuevo contrato UpgradeExecutor y un nuevo Consejo de Seguridad en la nueva chain L2.

2. Inicialice el nuevo L2 UpgradeExectutor con el alias de L1 Timelock y el nuevo Consejo de Seguridad como sus ejecutores.

3. Transferencia de propiedad: para una chain implementada cuyo despliegue de contrato refleje el de Arbitrum One y Arbitrum Nova (es decir, contratos centrales de Nitro y contratos puente de token), se debe realizar la siguiente transferencia de propiedad:

• El Ejecutor de update L1 debe recibir las siguientes prestaciones:
  ▪Propietario del administrador de proxy del contrato principal L1

  ▪Propietario del administrador del proxy del bridge del token L1

  ▪Propietario del administrador del rollup

  ▪Propietario del Gateway Router L1

  ▪Propietario del Gateway personalizado Arb L1

  • El nuevo Ejecutor de update L2 debe recibir las siguientes prestaciones:
    ▪Propietario del administrador del proxy del bridge del token

    ▪Propietario de la chain

    ▪Propietario de Beacon Proxy Arb-ERC20 estándar