Vogliamo garantire la futura aggiornabilità del sistema implementato in quanto prevediamo che la rete di Colonia sia continuamente sviluppata. Fornire un percorso di aggiornamento è importante per consentire alle persone di utilizzare Colon senza impedirsi di utilizzare nuove funzionalità man mano che vengono aggiunte alla rete. Intendiamo consentire l'aggiornamento di colonie e token utilizzando il modello reso disponibile con il nome EtherRouter. Questa implementazione utilizza due contratti in aggiunta ai contratti che forniscono la funzionalità implementata. Il primo contratto aggiuntivo è il contratto EtherRouter, che trasferisce transazioni e mdash; via delegatecall & mdash; al contratto che implementa quella funzione. Il secondo contratto aggiuntivo è il contratto Resolver, in cui sono definiti gli indirizzi dei contratti che implementano il comportamento desiderato. Ogni volta che una transazione viene ricevuta dal contratto EtherRouter, cerca il contratto che implementa quella funzione (se presente) nel Resolver, e quindi delegatecalls quel contratto. Per eseguire l'aggiornamento, i nuovi contratti vengono implementati con nuove funzionalità e quindi i contratti a cui fa riferimento il contratto Resolver devono essere modificati per puntare a questi nuovi contratti. Per evitare una situazione in cui il contratto implementa parzialmente funzionalità vecchie e nuove, verrà distribuita una nuova istanza di Resolver per ciascun aggiornamento e quindi una singola transazione può puntare EtherRouter sul nuovo Resolver. Ci assicureremo che nel caso di una colonia, la scelta di aggiornare il contratto di Colonia non sarà mai con la Rete di Colonia. Mentre la rete ha il controllo di quali aggiornamenti sono disponibili, non sono in grado di costringere nessuna colonia a migliorare i contratti sottostanti. La stessa colonia deve decidere che desidera eseguire l'aggiornamento a una nuova versione.
