#dusk $DUSK @Dusk
Minha tia mantém dois livros de registros separados para o negócio de aluguel de imóveis — um para rastrear qual unidade específica pertence a qual inquilino, e outro para acompanhar o total de aluguéis coletados neste mês. Perguntei por que não usar um só livro. Ela disse que propriedade individual e totais em execução respondem perguntas completamente diferentes, e obrigar um único livro a fazer as duas coisas torna ambas as respostas pouco confiáveis.
Eu assumi que o Zedger escolheria um modelo. Essa suposição caiu por terra quando eu tracei por que ele combina os dois, função por função.
Os materiais do Dusk listam cinco coisas que o Zedger especificamente suporta: liquidação e resgate em conformidade, impedindo usuários pré-aprovados de manterem mais de uma conta, distribuição de dividendos, votação e transferências com limite (cap). Eu separei em qual categoria cada necessidade realmente se encaixa, onde a fonte é específica o suficiente para indicar. Restrição de conta única e transferências com limite claramente precisam de verificação em tempo real do tipo “posição da conta” — este detentor específico já está acima de um limite, agora. Distribuição de dividendos e votação precisam de registro discreto e auditável por posição, mais próximo de rastreamento individual de notas no estilo UTXO.
Vale ser honesto aqui: os materiais do Dusk não esclarecem qual modelo específico lida com liquidação e resgate mecanicamente. Eu não vou adivinhar esse mecanismo apenas para a lista parecer completa.
Nenhum modelo sozinho cobre as funções que eu consegui confirmar. Um sistema apenas de conta tem dificuldade para provar uma posição passada específica para um “dividend-audit”. Um sistema apenas UTXO tem dificuldade para impor um limite em tempo real sem checar simultaneamente todas as notas.
O teste real para o DUSK é ver se este híbrido continua mantível conforme mais emissores configurem seus próprios limiares em cima dele.
A combinação de dois modelos contábeis resolve necessidades duplas genuínas, ou importa dois conjuntos de casos-limite em vez de um?
Minha tia mantém dois livros de registros separados para o negócio de aluguel de imóveis — um para rastrear qual unidade específica pertence a qual inquilino, e outro para acompanhar o total de aluguéis coletados neste mês. Perguntei por que não usar um só livro. Ela disse que propriedade individual e totais em execução respondem perguntas completamente diferentes, e obrigar um único livro a fazer as duas coisas torna ambas as respostas pouco confiáveis.
Eu assumi que o Zedger escolheria um modelo. Essa suposição caiu por terra quando eu tracei por que ele combina os dois, função por função.
Os materiais do Dusk listam cinco coisas que o Zedger especificamente suporta: liquidação e resgate em conformidade, impedindo usuários pré-aprovados de manterem mais de uma conta, distribuição de dividendos, votação e transferências com limite (cap). Eu separei em qual categoria cada necessidade realmente se encaixa, onde a fonte é específica o suficiente para indicar. Restrição de conta única e transferências com limite claramente precisam de verificação em tempo real do tipo “posição da conta” — este detentor específico já está acima de um limite, agora. Distribuição de dividendos e votação precisam de registro discreto e auditável por posição, mais próximo de rastreamento individual de notas no estilo UTXO.
Vale ser honesto aqui: os materiais do Dusk não esclarecem qual modelo específico lida com liquidação e resgate mecanicamente. Eu não vou adivinhar esse mecanismo apenas para a lista parecer completa.
Nenhum modelo sozinho cobre as funções que eu consegui confirmar. Um sistema apenas de conta tem dificuldade para provar uma posição passada específica para um “dividend-audit”. Um sistema apenas UTXO tem dificuldade para impor um limite em tempo real sem checar simultaneamente todas as notas.
O teste real para o DUSK é ver se este híbrido continua mantível conforme mais emissores configurem seus próprios limiares em cima dele.
A combinação de dois modelos contábeis resolve necessidades duplas genuínas, ou importa dois conjuntos de casos-limite em vez de um?
