Introducción

El cage-keeper es utilizado para facilitar el Apagado de Emergencia del Protocolo de Maker. El Apagado de Emergencia es un proceso complejo y determinista que requiere la interacción de todos los tipos de usuarios: dueños de vaults, holders de DAI, Keepers de redención, gobernadores de MKR y otras partes interesadas del Protocolo de Maker. Una visión general de alto nivel sería la siguiente:

1. Sistema Caged ("Enjaulado") - El Módulo de Seguridad de Emergencia (ESM) llama la función End.cage(), que congela el precio del USD para cada tipo de colateral así como muchas partes del sistema.
2. Periodo de Procesamiento - Después, los dueños de vaults interactúan con End para liquidar sus vaults y retirar el exceso de colateral. Las subastas se dejan concluir o se retiran antes de la redención de DAI.
3. Redención de DAI - Después de transcurrido el período de procesamiento End.wait se supone que la liquidación de vaults y todo el proceso de generación de DAI (subastas) han concluido. A este punto, los holders de DAI pueden empezar a reclamar una cantidad proporcional para cada tipo de colateral a una tasa fija.

Para evitar una race-condition ("condición de carrera") para los holders de DAI durante el Paso 3, es imperativo que cualquier vault que tenga un ratio de colateralización de menos del 100% en el Paso 1 sea procesada durante el Paso 2. El dueño de una vault underwater no recibiría un exceso de colateral, por lo que carecen de incentivos para skim sus posiciones en el contrato End. Por lo tanto, es responsabilidad de una de las partes interesadas de MakerDAO (holders de MKR, grandes holders de DAI, etc) asegurar que el sistema facilite una fase de redención de DAI sin una variable de tiempo. El cage-keeper es una herramienta para ayudar a las partes interesadas a cargar con esta responsabilidad.

Requisitos Previos

La siguiente sección asume que estás familiarizad@ con el Apagado de Emergencia. Algunos buenos lugares para empezar son el Módulo de Apagado de Emergencia en la Sección 3 y Sección 4 del Protocolo Maker 101 así como una descripción técnica más completa. Las Funciones mencionadas provienen de la implementación contenida por el contrato End, que esta localizado aquí.

Para ser consistente con la terminología técnica del Protocolo para el resto de esta descripción:

• urn = Vault
• ilk = Tipo de Colateral

Arquitectura

El cage-keeper interactúa directamente con los contratos End, Flopper y Flapper.

El objetivo central del cage-keeper es procesar todas las urns subcolateralizadas. Este paso contable se lleva a cabo dentro de End.skim() y dado que está rodeado por otros pasos importantes/requeridos en el Apagado de Emergencia, una primera iteración de este Keeper ayudará a llamar la mayoría de las otras funciones publicas dentro del contrato End.

Como se puede ver en el diagrama de flujo, el keeper revisa si el sistema ha sido caged ("enjaulado") antes de intentar skim todas las underwater urns y skip todas las funciones flip. Después que se ha facilitado el período de procesamiento y se ha alcanzado el tiempo de espera End.wait, hará la transición del sistema a la fase de redención de DAI del Apagado de Emergencia llamando a End.thaw() y End.flow(). Esta primera iteración de este Keeper es ingenua, ya que asume que es el único Keeper e intenta dar cuenta de todas las urns, ilks y subastas. Debido a esto, es importante que la dirección del Keeper tenga suficiente ETH para cubrir los costos de gas que implica enviar numerosas transacciones. Cualquier transacción que intenta llamar una función que ya ha sido invocada por otro Keeper/usuario simplemente fallará.

Operación

Este Keeper puede ejecutarse de forma contínua en una maquina local/virtual o se puede ejecutar cuando el operador se vuelve consciente del Apagado de Emergencia. Un ejemplo del script de la startup se muestra a continuación. La dirección Keeper de Ethereum debería tener suficiente ETH para cubrir los costos de gas y es una función del estado del protocolo al momento del apagado (es decir mas urns para skim, significa que se requiere mas ETH para cubrir los costos de gas). Cuando un nuevo tipo de colateral es agregado al protocolo, el operador debe sacar la ultima versión del Keeper, que incluiría contratos asociados con los tipos de colateral antes mencionados.

Después que el cage-keeper facilita el período de procesamiento, se puede apagar hasta que casi alcance End.wait. Después, en ese punto, el operador pasaría el argumento --previous-cage durante el inicio del Keeper para poder saltarse la función que soporta al período de procesamiento.

Instalación