shareyourthinking

Compromisso de confiabilidade de dependência de atestação de smart contract

Tenho pensado sobre isso há alguns dias porque eu já adicionei dependências de terceiros a smart contracts antes, e a questão sempre bate na mesma barreira: o que acontece com meu protocolo se a dependência cair.

Newton exige que aplicações validem uma atestação BLS em seu smart contract antes de executar. Sem atestação válida, não há execução.

Esse é o mecanismo de imposição e também uma dependência rígida.

Assim que um protocolo implanta esse requisito em um contrato imutável, ele se comprometeu com a disponibilidade da rede de operadores da Newton para cada transação que aquele contrato jamais processar.

Isso não é uma crítica. É uma escolha de design com implicações reais.

Um protocolo que integra Newton não confia apenas no seu próprio código.

Ele confia que um quorum de operadores com stake avaliará políticas e produzirá atestações para cada transação indefinidamente. O whitepaper aborda censura via forceinclusion. Ele não aborda o que acontece durante degradação genuína da rede de operadores — não censura, mas queda de desempenho ou indisponibilidade parcial.
#newt
Na verdade, eu acho que o compromisso de confiabilidade é a pergunta que mais importa para as equipes de protocolo ao avaliar a Newton, mais do que o conjunto de recursos de conformidade. Adicionar uma dependência a um smart contract é permanente de um jeito que adicionar uma a um serviço web não é.
#NEWT
O que eu ainda não descobri é se existe um modo de degradação graciosa — algum modo de um protocolo fazer fallback durante interrupções de operadores, em vez de simplesmente parar completamente.
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt

Os limites de reclamação do Faucet determinam se o Testnet realmente testa algo próximo do Uso Real ou apenas confirma se o pipeline funciona em um tamanho trivial.

#baby A faucet que distribui uma quantidade fixa Pequena por carteira está tudo bem para confirmar que o mecanismo de depósito para empréstimo funciona. Não está bem para testes de estresse do que acontece com os cálculos do fator de saúde, os Gatilhos de Liquidação ou o comportamento de pools do Aave v4 em tamanhos de posição que cheguem perto do que os usuários do mainnet realmente depositariam. Testnet de Trustless Bitcoin Vaults (TBV) existe especificamente para validar o Design antes que capital real passe por ele — mas essa validação só é tão boa quanto os tamanhos de posição que estão sendo de fato testados.$BABY

Não estou dizendo que um Faucet com limite seja uma falha de design. Faucets sem limite são drenados ou Abusados e a maioria dos testnets limita exatamente por esse motivo.

Também não estou dizendo que o limite não importa: se todos os testadores trabalham com o mesmo pequeno lote, certos modos de falha — liquidações em cascata, problemas de profundidade do P00l, casos-limite do fator de saúde em posições maiores — simplesmente não são exercitados antes do mainnet.@BabylonLabs_io

O que eu ainda não resolvi é se o limite baixo de reclamação reflete uma precaução genuína de Segurança contra abuso do faucet ou se está, silenciosamente, limitando o quanto de Teste de Estresse real a fase do Testnet pode produzir antes de o capital do mainnet estar em risco.
$AKE
$BANK #ShareYourThinking