#termmax @TermMax Si el proyecto me dijera “el contrato principal no se puede actualizar”, yo no aplaudiría de inmediato. Cuando realmente aparezca un bug, ¿que no se pueda actualizar será una barandilla que protege, o simplemente dejará el problema “bloqueado” para siempre? La explicación de actualización de TermMax da una respuesta relativamente clara: UUPS solo se coloca en AccessManager y TermMaxRouter; la lógica del protocolo central no está dentro del alcance de actualización.
Leí estas limitaciones de permisos varias veces y descubrí que, en realidad, está haciendo un equilibrio. El sistema de enrutamiento y permisos necesita dejar espacio para correcciones; por el contrario, las reglas centrales del propio préstamo se procura que no sean cambiables de forma casual por un administrador. Para los usuarios, la desventaja es que, si una lógica central falla de verdad, no se puede esperar que el backend emita una actualización y lo arregle; para los integradores, la ventaja es que cuando la infraestructura se actualice, las reglas de préstamo no se cambian “por accidente” sin querer.
El problema vendrá en el peor momento. Supongamos que un contrato de enrutamiento detecta una vulnerabilidad grave; la reparación tendría que pasar por multisig 4/6, así que los usuarios primero podrían enfrentarse a una pausa, esperar y volver a confirmar. Y si el problema cae justo dentro de la lógica central que no se puede actualizar, el equipo quizá solo pueda aislar el impacto, en lugar de reemplazar el código directamente. La flexibilidad y la determinación chocan, precisamente, de frente en un incidente.
Por eso, cuando observo el diseño de actualización de @TermMax , no solo cuento “cuántas firmas hacen falta para aprobar”. Me importa más con qué capa se topa cada actualización: si con la capa de entrada y permisos, o con las reglas centrales que los usuarios creían que no cambiarían. La confianza que $TMX busca construir no es prometer que nunca habrá problemas, sino hacer que cada alcance actualizable pueda ser verificado por terceros. #TermMax
Leí estas limitaciones de permisos varias veces y descubrí que, en realidad, está haciendo un equilibrio. El sistema de enrutamiento y permisos necesita dejar espacio para correcciones; por el contrario, las reglas centrales del propio préstamo se procura que no sean cambiables de forma casual por un administrador. Para los usuarios, la desventaja es que, si una lógica central falla de verdad, no se puede esperar que el backend emita una actualización y lo arregle; para los integradores, la ventaja es que cuando la infraestructura se actualice, las reglas de préstamo no se cambian “por accidente” sin querer.
El problema vendrá en el peor momento. Supongamos que un contrato de enrutamiento detecta una vulnerabilidad grave; la reparación tendría que pasar por multisig 4/6, así que los usuarios primero podrían enfrentarse a una pausa, esperar y volver a confirmar. Y si el problema cae justo dentro de la lógica central que no se puede actualizar, el equipo quizá solo pueda aislar el impacto, en lugar de reemplazar el código directamente. La flexibilidad y la determinación chocan, precisamente, de frente en un incidente.
Por eso, cuando observo el diseño de actualización de @TermMax , no solo cuento “cuántas firmas hacen falta para aprobar”. Me importa más con qué capa se topa cada actualización: si con la capa de entrada y permisos, o con las reglas centrales que los usuarios creían que no cambiarían. La confianza que $TMX busca construir no es prometer que nunca habrá problemas, sino hacer que cada alcance actualizable pueda ser verificado por terceros. #TermMax