Análise de 莫信|TapeKey chega: permissões de escrita em sites DeWEB podem ser emprestadas por tempo limitado, por até 30 dias

TapeKey(@tapekeyofficial)é um aplicativo de terceiros recém-lançado no ecossistema TapeOut. Ele gerencia as permissões de escrita dos contêineres de circuito DeWEB: permite emprestar a desenvolvedores, ferramentas de publicação automática ou agentes de IA a permissão para escrever no site, por até 30 dias. Ao fim do prazo, ela expira automaticamente e pode ser revogada a qualquer momento.

A seguir, explico o que essa «chave» representa on-chain, quem definiu o limite de 30 dias e quantas vezes ela já tinha sido usada antes do lançamento do TapeKey.

🐋 Primeiro, os contêineres

- Cada NFT de circuito está vinculado a uma conta chamada «contêiner». Cada contêiner corresponde a um site DeWEB
- Os arquivos do site são gravados no contrato de registro de sites da TapeOut. Por padrão, apenas o titular do NFT de circuito pode escrever
- Para permitir que colegas, scripts de publicação ou IA ajudem a atualizar o site sem entregar a chave privada da carteira, é preciso usar essa chave

🐋 A chave é o «operador» do contrato

O contrato de registro de sites já tem uma opção para definir um operador: o titular especifica um endereço e um prazo, e esse endereço pode editar os arquivos do site durante esse período. A chave mencionada pelo TapeKey é justamente isso, e a página do TapeKey também deixa claro que «nenhum contrato novo é adicionado».

- Cada contêiner só pode ter uma chave ativa por vez; uma nova substitui a antiga
- O prazo mínimo é de 1 segundo e o máximo, de 30 dias
- A chave só pode escrever o conteúdo do site: não pode transferir o NFT de circuito nem movimentar os ativos do contêiner
- Quando o circuito é transferido, a chave emitida pelo titular anterior é automaticamente invalidada
- Após a revogação, a outra pessoa não pode mais escrever imediatamente; o conteúdo já escrito permanece inalterado

As três últimas informações constam na página do TapeKey.

O limite de 30 dias é definido pelo próprio contrato. Fiz testes na BNB Chain usando o endereço de um titular de contêiner (simulação de transação, sem enviar para a blockchain, 22/10 às 22:59):

- Prazo de 2.592.000 segundos, exatamente 30 dias: aceito
- Mais 1 segundo: o contrato rejeita
- Tentar definir usando um endereço que não seja o do titular: o contrato rejeita

🐋 Antes do TapeKey, essa chave já havia sido emitida 603 vezes

No contrato de registro de sites da BNB Chain, desde a primeira definição de operador, em 8/9, até 30/10 às 21:01:

- 607 registros no total, envolvendo 142 contêineres: 603 emissões de chave e 4 revogações
- 537 endereços receberam chaves, a maioria apareceu apenas uma vez
- 598 emissões tiveram prazo de até 1 dia, das quais 480 foram de exatamente 24 horas; 5 tiveram prazo superior a 1 dia, e 1 foi de 30 dias
- A taxa para emitir uma chave é de aproximadamente 0,000006 BNB

https://bscscan.com/address/0xd006ffdd5Ae313B17729621A00999cD3C71CE5e6#events

Um endereço novo por vez, com prazo de um dia: suponho que a maioria seja de carteiras temporárias usadas por ferramentas de publicação. Esse também é o principal caso de uso listado na página do TapeKey: CI, GitHub Actions e carteiras temporárias do TapeCode. A máquina publica o site por você, e você só lhe dá uma chave com prazo limitado.

🐋 O TapeKey adiciona uma página de gerenciamento

- Conecte a carteira para listar seus contêineres na BNB Chain, X Layer e Base e ver quem tem a chave de cada contêiner e quanto tempo resta
- Emitir, substituir, renovar ou revogar chaves: cada etapa exige que a carteira assine uma transação on-chain
- Histórico de chaves: em qual bloco, quem definiu, para quem foi concedida e quando expira
- As chaves que expiram em até 24 horas são destacadas, e a página exibe um alerta quando está aberta
- A página lê apenas dados públicos on-chain, sem passar por servidores e sem acessar a chave privada

Dois meses de beta público. Gratuito durante o período de testes; o usuário paga o gas.

Hoje, uma chave pode editar o site inteiro. Será que no futuro será possível limitar o acesso a apenas um diretório, ou permitir somente acrescentar conteúdo, sem apagar?

——
Este artigo foi publicado originalmente no X: @musinoot