#termmax @TermMax Se o projeto me disser “o contrato principal não pode ser atualizado”, eu não vou aplaudir de imediato. Quando um bug aparecer de verdade, a falta de atualização é uma barreira de proteção ou é simplesmente travar o problema? A documentação de atualização do TermMax dá uma resposta relativamente clara: o UUPS fica apenas em AccessManager e TermMaxRouter; a lógica do protocolo central não está na faixa de contratos atualizáveis.
Eu li essa delimitação de permissões algumas vezes e percebi que ela, na verdade, faz concessões. O roteamento e o sistema de permissões precisam deixar espaço para correções; já as regras centrais do empréstimo devem, na medida do possível, impedir que um administrador mude algo “por impulso”. Para o usuário, a desvantagem é que, se um componente lógico central realmente der problema, não dá para contar que o backend resolva com uma simples atualização; para quem integra, a vantagem é que, quando a infraestrutura é atualizada, as regras de empréstimo não serão trocadas por engano.
A dificuldade aparece justamente nos momentos mais urgentes. Suponha que um contrato de roteamento encontre uma vulnerabilidade grave; para consertar é preciso passar por uma multisig 4/6, então o usuário pode primeiro ter que lidar com pausa, espera e uma re-confirmação. E se o problema, por acaso, estiver dentro da lógica central que não pode ser atualizada, o que o time talvez consiga fazer seja apenas isolar o impacto — e não substituir o código diretamente. Flexibilidade e determinismo, ironicamente, acabam se chocando de frente em uma ocorrência.
Por isso, ao analisar o design de upgrade do @TermMax , eu não conto apenas “quantas assinaturas precisam passar”. O que eu mais me importo é com qual camada exatamente cada atualização interage: é a entrada e permissões, ou são as regras centrais que o usuário acredita que não mudariam? A confiança que precisa ser construída depois do $TMX não é prometer que nunca haverá problemas, e sim garantir que cada faixa de escopo atualizável possa ser verificada por entidades externas. #TermMax
Eu li essa delimitação de permissões algumas vezes e percebi que ela, na verdade, faz concessões. O roteamento e o sistema de permissões precisam deixar espaço para correções; já as regras centrais do empréstimo devem, na medida do possível, impedir que um administrador mude algo “por impulso”. Para o usuário, a desvantagem é que, se um componente lógico central realmente der problema, não dá para contar que o backend resolva com uma simples atualização; para quem integra, a vantagem é que, quando a infraestrutura é atualizada, as regras de empréstimo não serão trocadas por engano.
A dificuldade aparece justamente nos momentos mais urgentes. Suponha que um contrato de roteamento encontre uma vulnerabilidade grave; para consertar é preciso passar por uma multisig 4/6, então o usuário pode primeiro ter que lidar com pausa, espera e uma re-confirmação. E se o problema, por acaso, estiver dentro da lógica central que não pode ser atualizada, o que o time talvez consiga fazer seja apenas isolar o impacto — e não substituir o código diretamente. Flexibilidade e determinismo, ironicamente, acabam se chocando de frente em uma ocorrência.
Por isso, ao analisar o design de upgrade do @TermMax , eu não conto apenas “quantas assinaturas precisam passar”. O que eu mais me importo é com qual camada exatamente cada atualização interage: é a entrada e permissões, ou são as regras centrais que o usuário acredita que não mudariam? A confiança que precisa ser construída depois do $TMX não é prometer que nunca haverá problemas, e sim garantir que cada faixa de escopo atualizável possa ser verificada por entidades externas. #TermMax