Documento traduzido CARDANO
Última parte
Zilliqa. Zilliqa é uma plataforma baseada em conta com uma abordagem para implementação de contrato inteligente
semelhante ao de Ethereum. Os tokens fungíveis e não fungíveis Zilliqa são projetados em uma
forma que imita os tokens ERC-20 e ERC-721, respectivamente. Embora este sistema seja projetado para
ser estaticamente analisável, não oferece novas soluções para o problema da dependência do global do
Estado.
DAML. DAML [7] é uma linguagem de contrato inteligente projetada para ser usada no modelo de razão DAML.
O modelo de razão DAML não suporta a manutenção de registros de propriedade de ativos, mas em vez disso, apenas
armazena estados de contrato atuais da seguinte maneira: uma transação válida interagindo com um contrato
resulta na criação de novos contratos que são as próximas etapas do contrato original e na remoção
do contrato original do razão.
Apenas os contratos com os quais uma transação interage são relevantes para validá-la, o que é
semelhante à nossa abordagem de validação sem contexto global. Embora este sistema não tenha
suporte integrado de múltiplos ativos (ou qualquer contabilidade em nível de razão), a transferência de qualquer tipo de ativo pode
ser representado no razão por meio de contratos. Devido ao design do sistema para operar inteiramente por
listar contratos no livro-razão, cada ação, incluindo a aceitação de fundos transferidos por um contrato,
requer consentimento. Esta é outra forma significativa pela qual este modelo é diferente do nosso
Bitcoin. O Bitcoin popularizou os livros razão UTXO, mas não tem suporte multi-ativos nativos nem não nativos
na rede principal. O modelo de razão Bitcoin não parece ter a contabilidade
infraestrutura ou contratos inteligentes suficientemente expressivos para a implementação de suporte multi-ativos em uma
forma genérica. Existem várias abordagens de camada dois para implementar ativos Bitcoin personalizados.
Como cada Bitcoin extraído é único, um Bitcoin específico pode representar um ativo personalizado específico, como
é feito em [3]. Uma estratégia de contabilidade mais sofisticada é implementada em outro costume de camada dois
abordagem de ativos [11]. Também houve tentativas de implementar tokens personalizados usando Lightning
canais de rede [1].
Tezos. Tezos [9] é uma plataforma baseada em contas com sua própria linguagem de contrato inteligente. Tem sido
usado para implementar um padrão de token fungível semelhante ao ERC-20 (FA1.2), com um padrão de token unificado
em andamento (ver [14]). Os tokens personalizados para ambos os padrões de multiativos são não nativos e, portanto,
têm deficiências semelhantes às dos padrões de token Ethereum.
Nervos CKB. Nervos CKB [17] é uma plataforma inspirada em UTXO que opera em uma noção mais ampla de
uma Célula, em vez do valor e endereço do saldo de saída normal, como o valor armazenado em uma entrada. UMA
A entrada na célula pode conter qualquer tipo de dados, incluindo um saldo em moeda nativa ou qualquer tipo de código.
Esta plataforma vem com uma linguagem de script Turing-completa que pode ser usada para definir
tokens nativos. Não há, no entanto, nenhuma infraestrutura de contabilidade dedicada para lidar com o costume comercial
ativos de forma semelhante ao tipo de moeda base.
7 DISCUSSÃO
7.1 Observações gerais
Registros de ativos e trocas distribuídas. A maneira mais óbvia de gerenciar ativos personalizados
pode ser adicionar algum tipo de registro de ativos global, que associa um novo grupo de ativos à sua política.
Uma vez que temos um registro de ativos, este se torna um lugar natural para colocar outros tipos de infraestrutura
que dependem do estado global associado a ativos, como trocas descentralizadas
No entanto, nosso sistema nos fornece uma maneira de associar as políticas de falsificação e os ativos controlados
por eles sem qualquer estado global. Isso simplifica a implementação do razão no concorrente e
ambiente distribuído de um blockchain. A introdução do estado global em nosso modelo resultaria na interrupção da sincronização (na qual [6] depende com grande efeito para implementar uma solução rápida e otimista),
bem como atualizações de estado lentas e caras no momento do registro do ativo. Portanto, no equilíbrio, nós
achamos que é melhor ter um sistema sem estado, mesmo que relegue recursos como trocas descentralizadas
para serem soluções da camada 2.
Políticas de gastos. Algumas plataformas que discutimos fornecem maneiras de expressar restrições na
transferência de tokens, não apenas em sua falsificação e queima, que chamamos de políticas de gastos.
Ao contrário de políticas de falsificação, políticas de gastos não são uma parte nativa de nosso sistema. Nós consideramos
uma série de abordagens para adicionar políticas de gastos, mas não encontramos uma solução que o faça
não colocar uma carga indevida sobre os usuários de tais tokens, tanto humanos quanto usuários programáticos, como
como protocolos de camada dois (por exemplo, Lightning). Por exemplo, seria necessário garantir que os gastos
as políticas não estão em conflito com scripts de falsificação ou bloqueio de saída (sempre que o ativo é gasto).
A falsificação de tokens requer uma ação específica do usuário (fornecendo e atendendo a uma política de falsificação
script), mas essa ação é sempre realizada conscientemente por um usuário que está especificamente tentando forjar
esses tokens. O gasto de tokens é, no entanto, uma operação completamente genérica que funciona de forma arbitrária
pacotes de tokens. Na verdade, uma virtude de nosso sistema é que todos os tokens personalizados têm aparência e comportamento uniforme.
Em contraste, as políticas de gastos tornam os tokens personalizados extremamente difíceis de manusear de uma forma genérica, em
particular para sistemas automatizados.
Esses argumentos não invalidam a utilidade das políticas de gastos, mas, em vez disso, destacam que
eles não são obviamente compatíveis com o comércio de ativos nativos de uma forma genérica, e uma abordagem
que trate dessas questões de uma forma ergonômica é muito necessária. Este problema não é só nosso:
políticas de gastos em outros sistemas que examinamos aqui (como Waves), não fornecem
soluções para os problemas que enfrentamos com as políticas de gastos também.
Scripts virais.
Uma maneira de emular as políticas de gastos em nosso sistema é bloquear todos os tokens com
um script específico que garante que eles permaneçam bloqueados pelo mesmo script quando transferidos. Nós
chamamos esse script de script “viral” (uma vez que se espalha para quaisquer novas saídas que estão “infectadas” com o
símbolo).
Isso permite que as condições do script sejam aplicadas em todas as transações que usam os tokens,
mas a custos significativos. Em particular, esses tokens nunca podem ser bloqueados por um script diferente, que
impede que tais tokens sejam usados em contratos inteligentes, bem como impede que uma saída
contendo tokens de dois desses grupos de ativos virais (uma vez que ambos exigiriam que seu validador
ser aplicado à saída!). Em alguns casos, no entanto, essa abordagem é exatamente o que queremos. Pra
exemplo, no caso de tokens de credencial, queremos que o script bloqueie a credencial para
permitir que o emissor acesse a credencial (a fim de manter sua capacidade de revogá-la).
Estado global. Existem limitações do nosso modelo devido ao fato de que as informações globais sobre
o razão não está disponível para o script de política de falsificação. Muitas restrições de estado global podem ser acomodadas com soluções alternativas (como no caso de tokens novos comprovadamente exclusivos), mas algumas não podem:
por exemplo, uma política de falsificação que permite que uma quantidade variável seja forjada em cada bloco, dependendo da oferta total atual de ativos de outra apólice. Esta é uma política estranha de se ter, mas, no entanto,
não aquele que pode ser definido em nosso modelo.
7.2 Conclusões
Apresentamos um modelo de razão de múltiplos ativos que se estende a um razão baseado em UTXO para que possa suportar
tokens fungíveis e não fungíveis personalizados. Fazemos isso de uma maneira que não exige um contrato inteligente. Adicionamos uma pequena linguagem com a capacidade de expressar exatamente a lógica de que precisamos para um
conjunto particular de casos de uso. Nosso livro razão UTXOma junto com esta linguagem nos permite usar
ativos para suportar uma ampla variedade de casos de uso, mesmo aqueles que normalmente não são baseados em “ativos”,
embora permaneça determinístico, de alta segurança e analisável.
Nosso design tem uma série de limitações, algumas das quais têm soluções alternativas aceitáveis e algumas não. Em particular, o acesso ao estado global de uma forma geral não pode ser suportado, e os gastos
as políticas não são fáceis de implementar. Também não é possível restringir explicitamente o pagamento a um endereço.
Consideramos essas orientações valiosas para melhorias futuras em nosso modelo.