Queremos garantizar la capacidad de actualización futura del sistema implementado, ya que prevemos que la red de colonias se desarrolle continuamente. Proporcionar una ruta de actualización es importante para permitir que las personas utilicen Colón sin evitar que utilicen nuevas funciones a medida que se agregan a la Red. Tenemos la intención de permitir que las colonias y los tokens se actualicen utilizando el patrón disponible bajo el nombre EtherRouter. Esta implementación utiliza dos contratos, además de los contratos que proporcionan la funcionalidad implementada. El primer contrato adicional es el contrato EtherRouter, que pasa las transacciones y el mdash; a través de delegatecall y mdash; Al contrato que implementa esa función. El segundo contrato adicional es el contrato de resolución, donde se definen las direcciones de los contratos que implementan el comportamiento deseado. Cada vez que una transacción es recibida por el contrato EtherRouter, busca el contrato que implementa esa función (si corresponde) en Resolver, y luego vuelve a llamar ese contrato. Para actualizar, los nuevos contratos se implementan con una nueva funcionalidad, y luego los contratos a los que el Contrato Resolver apunta se deben cambiar para que apunten a estos nuevos contratos. Para evitar una situación en la que el contrato implemente parcialmente la funcionalidad antigua y la nueva, se implementará una nueva instancia de Resolver para cada actualización, y luego una sola transacción puede apuntar a EtherRouter hacia el nuevo Resolver. Nos aseguraremos de que, en el caso de una colonia, la opción de actualizar el contrato de Colony subyacente nunca corresponda a la red de Colony. Si bien la red tiene el control de las actualizaciones disponibles, no pueden obligar a ninguna colonia a actualizar los contratos subyacentes. La propia colonia debe decidir que quiere actualizarse a una nueva versión.
