Quase passou despercebido no changelog: zero dependências em tempo de execução. Escondido sob títulos maiores sobre o lançamento do SDK.
Leitura fácil: o Dusk Connect apenas torna o vínculo da carteira mais simples para os desenvolvedores. Sim, é isso mesmo: o SDK leve, plugue e pronto.
Ficando um pouco mais com ele, fica claro que a questão é realmente sobre quem controla a camada de conexão. A Dusk usa um padrão de descoberta baseado em eventos `dusk:announceProvider`, `dusk:requestProvider` modelado diretamente no EIP-6963 do Ethereum. Em vez de um dApp ficar codificando em torno de uma única carteira, ele transmite uma solicitação e deixa cada carteira compatível responder. O dApp nunca precisa saber qual carteira vence.
Veja o que fica em segundo plano: padronizar a descoberta não padroniza a confiança. Qualquer extensão pode ouvir esse evento de solicitação e se anunciar como provedor. O EIP-6963 resolveu a antiga condição de disputa do window.ethereum no Ethereum, mas não resolveu a personificação de carteiras — ele apenas transferiu a responsabilidade de verificar quais provedores são legítimos para o usuário, um prompt de conexão por vez.
O mesmo dilema aparece nas finanças tradicionais. APIs de open banking padronizaram como apps de terceiros solicitam acesso à conta, mas um formato de solicitação padronizado nunca garantiu que quem pedia era seguro — bancos continuam adicionando telas separadas de consentimento e verificação por exatamente esse motivo.
Meu primeiro instinto foi que zero dependências significava apenas uma instalação mais enxuta. Vai além disso: menos dependências também significa menos lugares onde uma falha de comprometimento da supply chain possa se esconder e menos desculpas caso alguma passe por qualquer forma.
Você prefere ver a Dusk focar em seguida em mais provedores de carteira adotando isso, ou em reforçar como os dApps verificam com qual provedor eles realmente estão falando?
@Dusk #dusk $DUSK
Leitura fácil: o Dusk Connect apenas torna o vínculo da carteira mais simples para os desenvolvedores. Sim, é isso mesmo: o SDK leve, plugue e pronto.
Ficando um pouco mais com ele, fica claro que a questão é realmente sobre quem controla a camada de conexão. A Dusk usa um padrão de descoberta baseado em eventos `dusk:announceProvider`, `dusk:requestProvider` modelado diretamente no EIP-6963 do Ethereum. Em vez de um dApp ficar codificando em torno de uma única carteira, ele transmite uma solicitação e deixa cada carteira compatível responder. O dApp nunca precisa saber qual carteira vence.
Veja o que fica em segundo plano: padronizar a descoberta não padroniza a confiança. Qualquer extensão pode ouvir esse evento de solicitação e se anunciar como provedor. O EIP-6963 resolveu a antiga condição de disputa do window.ethereum no Ethereum, mas não resolveu a personificação de carteiras — ele apenas transferiu a responsabilidade de verificar quais provedores são legítimos para o usuário, um prompt de conexão por vez.
O mesmo dilema aparece nas finanças tradicionais. APIs de open banking padronizaram como apps de terceiros solicitam acesso à conta, mas um formato de solicitação padronizado nunca garantiu que quem pedia era seguro — bancos continuam adicionando telas separadas de consentimento e verificação por exatamente esse motivo.
Meu primeiro instinto foi que zero dependências significava apenas uma instalação mais enxuta. Vai além disso: menos dependências também significa menos lugares onde uma falha de comprometimento da supply chain possa se esconder e menos desculpas caso alguma passe por qualquer forma.
Você prefere ver a Dusk focar em seguida em mais provedores de carteira adotando isso, ou em reforçar como os dApps verificam com qual provedor eles realmente estão falando?
@Dusk #dusk $DUSK
