UTXOs nativos no Ethereum – Página 2 – Pesquisa da camada de execução

Penso que concordamos que não deve haver um mundo onde todos os nós podem a história. Portanto, por muitos outros motivos além do UTXO, contamos com alguns nós que mantêm o histórico. Então a questão é mais como um usuário verifica se há utxos. Uma opção é usar uma carteira. Muito semelhante ao que outras cadeias estão fazendo, por exemplo, zcash, mondero ou bitcoin, pode-se ter um lightclient inserido na carteira e usar o p2p para solicitar utxos filtrados por recipient do arquivo/nós completos.

Muito semelhante se aplica aos protocolos de privacidade onde os usuários também precisam reconstruir as folhas de teste para criar a prova contra uma raiz merkle recente. Vejo o problema mais no fato de não termos tipos de nós que sejam leves (com estado parcial), ao mesmo tempo que permitem sincronizar utxos para determinados destinatários filtrados – mas isso é algo que pode ser construído – estamos muito adiantados com esta proposta.

Penso que há aqui duas lacunas distintas que vale a pena manter separadas, porque uma é edificável e a outra é um comércio genuíno.

1. Descoberta versus privacidade (a mais profunda). O modelo de cliente leve que você descreve, filtrando UTXOs por destinatário em p2p, funciona para pagamentos transparentes, mas quebra exatamente no caso de endereço furtivo que a proposta destaca. Qualquer consulta eficiente o suficiente para encontrar meu dinheiro identifica o que é meu para quem o entrega. A alternativa é baixar tudo e escanear às cegas, e é por isso que as redes que você cita como precedentes têm uma sincronização de carteira notoriamente pesada. Esse comércio não pode ser incentivado, apenas mitigado (tags de dicas digitalizáveis, chaves de visualização, downloads de filtros). A preocupação: o formato de abertura escolhido agora decide quais mitigações permanecerão possíveis posteriormente. É uma porta de mão única disfarçada de detalhe de implementação. A especificação precisa reservar espaço para uma dica de detecção hoje, mesmo que não seja utilizada?
2. Retenção (a que pode ser resolvida). “Alguns nós manterão aberturas” atualmente não há resposta para o porquê disso. Mas a correção pode ser construída a partir de partes já incluídas na proposta: garantir uma pequena recompensa de retenção na criação do UTXO, exigível por quem fornece a abertura no gasto, verificada em relação à raiz de aberturas que você já está comprometendo por bloco. O criador-pagador internaliza o preço onde ele pertence, a recompensa viaja com o UTXO e, como bônus, elimina a existência do luto pela cunhagem de poeira. Taxas de recuperação pagas pelo gastador ou desafios de custódia apostados são alternativas, mas o pagador do criador precisa de menos maquinário novo.
   A retenção é um espaço de design não reclamado; a descoberta é uma tensão inerente. Separá-los parece útil antes de o formato ser definido.

Endereços furtivos podem ser complementares e úteis, mas não vejo que tenham as mesmas propriedades. Se seguir o ERC-5564 conforme pretendido, você ainda verá o fluxo completo de transações. Um mixer ou pool blindado deve eventualmente ser usado para quebrar o link do remetente. No exemplo do pool protegido que compartilhei, entretanto, nada seria revelado. Nem remetente, destinatário, nem valor.

Agora se data não está no objeto, mas é possível agrupar transações aqui, então sim, verdadeiros compromissos podem ser feitos para alcançar algum nível de paridade. Para o exemplo do pool protegido, você poderia tecnicamente emitir um log de eventos que inclua os dados adicionais. O problema com isso é que fica muito mais caro e complicado provar o lado do cliente em um zkSNARK. Outra opção para evitar isso é, em vez disso, fazer hash desses dados como um compromisso e inseri-los em uma árvore merkle separada em um contrato inteligente. Então, no zkSNARK, estou provando a inclusão da nota UTXO e de seu compromisso correspondente em suas respectivas árvores. Isso é muito rápido e barato para fazer do lado do cliente, mas a compensação seria o alto custo do gás de cada compromisso inserido na árvore Merkle separada. Existem maneiras de torná-lo mais eficiente em termos de gás, mas ainda assim não é ideal. Em comparação com ambas as opções, apenas ter data no objeto UTXO seria muito mais simples e econômico.

Para contrapor ao meu exemplo de garantia, isso também pode ser incluído em uma transação para algum contrato inteligente que mapeia a nota UTXO para um unlocked_at o carimbo de data e hora e, posteriormente, o endereço de garantia podem verificá-lo como um quadro de verificação e liberar fundos como uma nova nota UTXO para o destinatário. Não sei se há algo a ganhar com o uso de UTXOs nativos para esse caso de uso específico, mesmo que seja uma espécie de depósito privado, se for necessário atualizar o estado em outro contrato inteligente. Admito, porém, que o exemplo do depósito serviu apenas para provar que vários casos de uso se abrem com data incluído. Acho que pode haver muitos mais.

Além disso, não acho que um verificador precise ser consagrado para isso. Pelo que entendi do EIP-8141, você pode verificar uma prova zk em um quadro. Se isso for falso, então seria uma chatice incrível.

Concordo, e seu data campo também resolve um segundo problema: descoberta. Uma vez que os fluxos são furtivos ou protegidos, o filtro por destinatário é interrompido por design e as carteiras se revelam para um nó de serviço ou fazem uma verificação experimental de tudo, e é por isso que a sincronização Zcash/Monero é tão pesada. Toda mitigação conhecida precisa da mesma coisa: um pequeno auxílio de digitalização anexado a cada saída. O mais barato, uma etiqueta de visualização à la EIP-5564, custa um byte por pagamento para uma digitalização aproximadamente 256x mais rápida com vazamento insignificante.

Essa ajuda e sua nota criptografada são apenas cargas diferentes para um slot. Portanto, a solicitação unificada é pequena: uma solicitação de comprimento variável, versionada e opaca ao protocolo. data campo na abertura. Custa um prefixo de comprimento agora; adicioná-lo após a implantação é uma bifurcação de codificação. Dois casos de uso independentes convergindo para o mesmo campo antes que a especificação seja finalizada parecem uma boa evidência de que é estrutural.

WIP EIP-8304 pode ser mais adequado para evitar casos de falsos positivos e obter gratuitamente provas de integridade do log do lado do cliente. O problema com os dados históricos ainda permanece, pois o contrato do sistema só manteria raízes por aproximadamente 30 dias.

Mas atualmente a indexação de logs do lado do cliente em tempo real é realmente irrealista e até mesmo os projetos existentes que utilizam o ERC-5564 mudaram sua arquitetura para não usar logs para descoberta.

A outra área potencial de pesquisa poderia ser implementações de endereços furtivos com segurança PQ e esta proposta trabalhando em conjunto. Como a magia do ecdh simplesmente pararia de funcionar em algum momento

Sim, 8304 seria ótimo e UTXOs como caso de uso fortalecem o argumento para enviá-lo.
Eu acho que história! = história. Por exemplo, ainda poderíamos podar tudo o que hoje chamamos de história, mas analisar os logs de eventos UTXO e mantê-los. Tipo, trate-os de maneira especial, pelo menos de forma opcional, por exemplo.

A retenção opt-in ainda tem o problema do altruísmo: funciona para os dados que alguém já deseja e falha para os dados de cauda longa, que são exatamente os dados que correm maior risco. É isso que uma recompensa no tempo de criação resolve: cada UTXO cobra uma pequena taxa que vai para quem manteve seus dados quando eles finalmente forem gastos. O armazenamento torna-se um trabalho remunerado em vez de um favor. O tratamento especial precisa de um pagador, não de um voluntário.

Estamos armazenando as raízes de uma árvore (ou qualquer acumulador) por bloco. Então, depois de gastar esse UTXO, não podemos zerar o seu compromisso e atualizar a árvore? Então, agora se eu tentar gastar zero leaf/utxo, o protocolo rejeita?

Além disso, endereços furtivos serão um ótimo caso de uso aqui. Acho que o maior gargalo será a descoberta das notas/pagamentos. Os mecanismos de descoberta implementados até agora em diferentes protocolos ainda degradam a experiência do usuário. Uma solução viável poderia ser emprestada a pesquisa dos esforços do projeto ZCash Tachyon.