Tempo propõe TIP-1061 para introduzir contas multi-assinatura nativas na camada de governação, sem necessidade de implementar contratos como o Safe

A blockchain de camada 1 Tempo, desenvolvida em conjunto pela Stripe e pela Paradigm, apresentou no dia 31 de maio uma proposta TIP-1061 para contas nativas de multisig, com o objetivo de introduzir o multisig como o principal tipo de conta da camada de protocolo na rede, permitindo controlar o multisig sem necessidade de fazer deploy de carteiras de contratos inteligentes como o Safe. A TIP-1061 está sobretudo orientada para casos de utilização como DAOs, entidades institucionais e nós de validação, e continua ainda na fase de rascunho.

Especificações técnicas confirmadas

O desenho central da TIP-1061 inclui os seguintes detalhes técnicos já confirmados. O endereço da conta de multisig deriva da hash da configuração inicial (config_id); quando se ajusta posteriormente a lista de membros, o peso das assinaturas ou o limiar (threshold), o endereço da conta mantém-se inalterado.

São suportados três tipos de assinaturas: Secp256k1, P256 e WebAuthn. O protocolo suporta multisig “M-of-N” (cada owner com weight=1) e multisig ponderado (autorização assimétrica), por exemplo, um owner de maior peso (weight=100) pode autorizar sozinho, ou dois owners de peso intermédio (cada um com weight=50) podem autorizar em conjunto. Cada conta multisig permite no máximo 10 owners (MAX_MULTISIG_OWNERS=10).

Limitações de desenho: não suporta AccountKeychain e EIP-7702

A TIP-1061 estabelece de forma explícita que a conta nativa de multisig não suporta acesso a chaves via AccountKeychain; se msg.sender for uma conta nativa de multisig, tem de ser recusada a chamada do modificador AccountKeychain. A razão de desenho proposta é a seguinte: permitir que uma chave de autorização única realize chamadas como identidade de conta “pai” transformaria uma chave privada original numa capacidade permanente para atuar como endereço de multisig dentro de qualquer âmbito de autorização, o que não corresponde ao princípio de desenho de “controlo de identidade pelo número legal de pessoas”.

Além disso, após o Bootstrap, a conta nativa de multisig não pode instalar bytecode EVM nem código de delegação do EIP-7702.

Estado do rascunho: assuntos ainda por confirmar

A proposta continua a ser um rascunho; tanto o esquema de contagem de gas (o documento marca como “pendente”) como os endereços dos contratos pré-compilados de multisig (que serão atribuídos antes da proposta sair da fase de rascunho) ainda não estão finalizados. A proposta determina que, antes de a TIP-1061 entrar em vigor, todas as transações que incluam TempoSignature::Multisig têm de ser recusadas; todas as transações que contenham o campo multisig_init também têm de ser recusadas antes de a proposta arrancar.

Perguntas frequentes

Qual é a diferença essencial entre o multisig nativo da TIP-1061 e carteiras de contratos como o Safe?

A TIP-1061 eleva a validação do multisig para a camada de protocolo; não é necessário fazer deploy em cadeia de carteiras de contrato como o Safe para obter a mesma capacidade de controlo por limiar. Isto elimina os custos de deploy de contratos e, após derivar o endereço da conta da configuração inicial, esse endereço mantém-se estável, sem mudar quando os membros são atualizados.

Porque é que o endereço da conta multisig consegue manter-se inalterado após atualizações dos membros?

O endereço da conta multisig é derivado da hash de config_id; o config_id é calculado a partir do conjunto inicial de owners (incluindo endereços, tipo de assinatura e peso) e do limiar, e não muda durante a existência da conta. Chamadas posteriores a updateMultisigConfig apenas atualizam a configuração atualmente guardada, sem alterar o próprio config_id nem o endereço de conta derivado.

Quais são os principais cenários de utilização para a TIP-1061?

A secção de motivação da proposta indica explicitamente que o objetivo são utilizadores que precisam de “garantir que nenhuma chave privada única pode, por si só, transferir fundos ou alterar configurações operacionais”. Isto inclui equipas (Teams), departamentos de tesouraria (Treasury), validadores (Validators) e operadores institucionais (Institutional Operators).