Ontem à noite, revisei a página do endereço do contrato oficial do começo ao fim. Depois de cada contrato havia um número de versão; a rede de testes Sepolia e o planejamento para a mainnet aparecem separados em duas linhas. A página é curta, mas traz bastante informação. O próprio endereço também serve como evidência: ativos de teste e ativos reais se separam desde a entrada.
Os três componentes — Registry do Vault, ProtocolParams e adaptadores — têm, cada um, três identificadores correspondentes: a versão do Vault Core, a versão dos parâmetros off-chain e a versão do conjunto de participantes. No começo eu não dei importância a esses números; pensei que as versões fossem um assunto dos desenvolvedores. @BabylonLabs_io
Depois, cotei as descrições de duas suítes de ambiente e entendi o que elas travam: no registro do vault, a regra de vinculação é por versão. Um vault, desde o momento em que é criado, já fica “amarrado” àquele conjunto de parâmetros; atualizações posteriores não podem alterar silenciosamente as regras originais. Em geral, após o número de versão vêm a data e os registros de deployment; antes e depois da atualização, dá para comparar item a item as diferenças. Os parâmetros de deployment de cada suíte de ambiente (rede de testes e mainnet) têm valores próprios — exatamente por isso o campo “versão” precisa ser registrado em separado. A trava por versão traz um problema prático: o fluxo validado na rede de testes, ao ser usado com o endereço da mainnet, não pode ser simplesmente copiado; é preciso refazer todo o processo de deployment e validação.
A forma como o oficial lista as duas suítes separadamente é, por si só, um aviso: no ambiente de ativos, cada deployment representa uma fronteira de confiança independente. O comportamento verificado pela versão do contrato na rede de testes só prova o que é válido para a suíte de testes. $BABY
Antes eu achava que, se na rede de testes funcionasse, dava para ir direto para a mainnet; lendo com atenção, percebi que o valor dos rótulos de ambiente e dos números de versão na página não é menor do que o de um documento funcional. No fim, a conclusão é: ao ler materiais de TBV, primeiro confirme de qual suíte de ambiente ele está falando, depois veja o número de versão e, por último, somente então analise a descrição da funcionalidade. Entre os endereços de rede de testes e mainnet, o que existe no meio é todo o conjunto de deployment e validação, não “um clique”. O isolamento de ambientes na ecologia é um design, não uma omissão.
Voltando àquela página da noite passada: duas linhas de endereços são dois mundos. O rótulo de ambiente e o número de versão valem mais para ler primeiro do que a descrição de funcionalidade. #baby
Os três componentes — Registry do Vault, ProtocolParams e adaptadores — têm, cada um, três identificadores correspondentes: a versão do Vault Core, a versão dos parâmetros off-chain e a versão do conjunto de participantes. No começo eu não dei importância a esses números; pensei que as versões fossem um assunto dos desenvolvedores. @BabylonLabs_io
Depois, cotei as descrições de duas suítes de ambiente e entendi o que elas travam: no registro do vault, a regra de vinculação é por versão. Um vault, desde o momento em que é criado, já fica “amarrado” àquele conjunto de parâmetros; atualizações posteriores não podem alterar silenciosamente as regras originais. Em geral, após o número de versão vêm a data e os registros de deployment; antes e depois da atualização, dá para comparar item a item as diferenças. Os parâmetros de deployment de cada suíte de ambiente (rede de testes e mainnet) têm valores próprios — exatamente por isso o campo “versão” precisa ser registrado em separado. A trava por versão traz um problema prático: o fluxo validado na rede de testes, ao ser usado com o endereço da mainnet, não pode ser simplesmente copiado; é preciso refazer todo o processo de deployment e validação.
A forma como o oficial lista as duas suítes separadamente é, por si só, um aviso: no ambiente de ativos, cada deployment representa uma fronteira de confiança independente. O comportamento verificado pela versão do contrato na rede de testes só prova o que é válido para a suíte de testes. $BABY
Antes eu achava que, se na rede de testes funcionasse, dava para ir direto para a mainnet; lendo com atenção, percebi que o valor dos rótulos de ambiente e dos números de versão na página não é menor do que o de um documento funcional. No fim, a conclusão é: ao ler materiais de TBV, primeiro confirme de qual suíte de ambiente ele está falando, depois veja o número de versão e, por último, somente então analise a descrição da funcionalidade. Entre os endereços de rede de testes e mainnet, o que existe no meio é todo o conjunto de deployment e validação, não “um clique”. O isolamento de ambientes na ecologia é um design, não uma omissão.
Voltando àquela página da noite passada: duas linhas de endereços são dois mundos. O rótulo de ambiente e o número de versão valem mais para ler primeiro do que a descrição de funcionalidade. #baby