A penumbra está lançando uma camada compatível com EVM
ao lado de sua cadeia nativa, e a lógica declarada é
simples:
reduzir a barreira para desenvolvedores, permitindo que
a infraestrutura Solidity existente se conecte
sem exigir que cada construtor aprenda um novo stack do zero.
À primeira vista, esta é a jogada óbvia — a
familiaridade com EVM é o maior grupo de desenvolvedores em cripto,
e recusar-se a encontrar esse ecossistema pela metade é o jeito
como L1s promissoras permanecem nichadas permanentemente.
O que não sai da minha cabeça, porém, é
uma questão mais específica:
uma camada compatível com EVM herda as garantias reais de privacidade da Dusk,
ou herda a transparência padrão do EVM e apenas fica ao lado da camada de privacidade da Dusk, sem tocá-la?
Não é a mesma coisa, e a distinção
importa mais aqui do que em
praticamente qualquer outro L1
ao adicionar compatibilidade com EVM, porque privacidade e conformidade com divulgações conscientes
são a razão de ser da existência da Dusk.
Se um contrato implantado na camada EVM se comporta
como qualquer outro contrato EVM — estado público, calldata pública,
o modelo padrão de transparência — então “a Dusk suporta EVM” e “o modelo de privacidade da Dusk se estende à EVM” são duas
alegações diferentes, e apenas o marketing tende a fazer
as duas ao mesmo tempo.
A versão honesta deste dilema é que compatibilidade com EVM e computação confidencial nativa
são, em certa medida, estruturalmente opostas.
O modelo de execução do EVM não foi criado pensando em divulgação seletiva;
a proposta de valor central da Dusk foi construída especificamente em torno disso.
Juntar as duas bem — permitindo
ferramentas familiares enquanto ainda se obtém transações confidenciais
e contratos inteligentes conscientes de conformidade — é um problema de integração realmente difícil, não um simples check.
É possível que a Dusk tenha resolvido isso de forma elegante.
Também é possível que “compatível com EVM” signifique silenciosamente
“compatível com EVM para a metade transparente da cadeia”,
enquanto os contratos que preservam a privacidade de fato ainda exigem a pilha nativa, XSC, e a curva de aprendizado que a compatibilidade com EVM pretendia remover.
@Dusk #dusk $DUSK
ao lado de sua cadeia nativa, e a lógica declarada é
simples:
reduzir a barreira para desenvolvedores, permitindo que
a infraestrutura Solidity existente se conecte
sem exigir que cada construtor aprenda um novo stack do zero.
À primeira vista, esta é a jogada óbvia — a
familiaridade com EVM é o maior grupo de desenvolvedores em cripto,
e recusar-se a encontrar esse ecossistema pela metade é o jeito
como L1s promissoras permanecem nichadas permanentemente.
O que não sai da minha cabeça, porém, é
uma questão mais específica:
uma camada compatível com EVM herda as garantias reais de privacidade da Dusk,
ou herda a transparência padrão do EVM e apenas fica ao lado da camada de privacidade da Dusk, sem tocá-la?
Não é a mesma coisa, e a distinção
importa mais aqui do que em
praticamente qualquer outro L1
ao adicionar compatibilidade com EVM, porque privacidade e conformidade com divulgações conscientes
são a razão de ser da existência da Dusk.
Se um contrato implantado na camada EVM se comporta
como qualquer outro contrato EVM — estado público, calldata pública,
o modelo padrão de transparência — então “a Dusk suporta EVM” e “o modelo de privacidade da Dusk se estende à EVM” são duas
alegações diferentes, e apenas o marketing tende a fazer
as duas ao mesmo tempo.
A versão honesta deste dilema é que compatibilidade com EVM e computação confidencial nativa
são, em certa medida, estruturalmente opostas.
O modelo de execução do EVM não foi criado pensando em divulgação seletiva;
a proposta de valor central da Dusk foi construída especificamente em torno disso.
Juntar as duas bem — permitindo
ferramentas familiares enquanto ainda se obtém transações confidenciais
e contratos inteligentes conscientes de conformidade — é um problema de integração realmente difícil, não um simples check.
É possível que a Dusk tenha resolvido isso de forma elegante.
Também é possível que “compatível com EVM” signifique silenciosamente
“compatível com EVM para a metade transparente da cadeia”,
enquanto os contratos que preservam a privacidade de fato ainda exigem a pilha nativa, XSC, e a curva de aprendizado que a compatibilidade com EVM pretendia remover.
@Dusk #dusk $DUSK