Visão geral dos recursos do Vasil

Pipelining de difusão

O pipelining de difusão é um recurso que melhora os tempos de propagação de blocos e leva a um maior throughput. Em essência, ele simplifica o processo de compartilhamento de informações sobre blocos recém-criados entre os participantes da rede. O objetivo desta atualização é garantir que os blocos possam ser compartilhados (propagados) na rede dentro de cinco segundos após sua criação. Para isso, o pipelining de difusão propaga os blocos antes de sua validação completa, sobrepondo o tempo gasto na difusão com o tempo necessário na validação.

O pipelining também garante que o cabeçalho do bloco referenciando o hash de um bloco anterior seja propagado corretamente. O corpo do bloco é retido dentro dos metadados incluídos no próximo bloco, o que é essencial para a resistência a ataques de negação de serviço (DDoS) mesmo sem confirmação completa do bloco.

O pipelining de difusão fornece mais espaço para aumentar o tamanho do bloco e melhorias no script Plutus, levando a uma configuração mais escalável no geral.

Mudanças no Plutus Core

O Plutus Core é uma linguagem de script usada no razão Cardano. Ele consiste em construções básicas de linguagem principais e também inclui tipos integrados (inteiros, strings etc.) e funções integradas (adição de inteiros etc.) que fornecem funcionalidades que seriam difíceis ou caras de implementar no código do Plutus Core. As funções integradas operam principalmente em tipos integrados. Os tipos integrados vêm com uma métrica de tamanho que é usada por funções de custo. Por exemplo, a métrica de tamanho para inteiros retorna o tamanho em bits do inteiro.

O desempenho dos scripts Plutus Core está relacionado a quão caro é executar um script no razão. O modelo de custo descreve as taxas de CPU e memória para cada primitiva de linguagem e pode ser usado fora da cadeia para prever taxas para a execução de tais scripts.

O desempenho do modelo é calculado por avaliação de custo em unidades de recursos abstratas (exunits) de CPU e memória. Etapas individuais de avaliação são custadas, e as funções integradas também devem vir com uma função de custo que fornece informações de custo para elas. A função de custo para uma função integrada é uma função matemática que leva os tamanhos dos argumentos (como calculado por suas métricas de tamanho) e retorna uma estimativa do orçamento que será usado para executar essa função.

Por exemplo, a função de custo para adição diz que os custos de CPU e memória são proporcionais ao máximo dos tamanhos dos inteiros de entrada (com algumas constantes apropriadas). A determinação das funções de custo é feita empiricamente executando a função em questão contra um grande número de entradas e escolhendo uma função de custo que se ajuste bem aos dados.

Scripts no razão Cardano

O razão Cardano reconhece vários tipos de scripts que são identificados pela versão da 'linguagem'. Esta tag de linguagem permite ao razão distinguir entre diferentes tipos de scripts. Quando um novo comportamento ou funcionalidade é introduzido, também é introduzida uma nova linguagem. Cada nova versão do Plutus será sua própria linguagem, e todas as versões de linguagem do Plutus Core são suportadas para sempre no razão. Isso fornece a capacidade de validar o histórico da cadeia indefinidamente.

Parte da especificação de uma linguagem no razão explica como os scripts da linguagem são executados, que argumentos eles recebem e como esses argumentos são estruturados. As linguagens também têm um subconjunto associado de parâmetros de protocolo Cardano que controlam alguns aspectos da avaliação do script. Para Plutus, este é o modelo de custo associado a cada nova versão da linguagem.

Melhorias na velocidade do avaliador Plutus

Devido a melhorias de desempenho no avaliador Plutus, tanto os scripts Plutus V1 quanto os Plutus V2 têm parâmetros de modelo de custo mais baixos do que antes, resultando em melhorias de 20-30% no uso de recursos de script.

Parâmetros do modelo de custo atualizados

Os parâmetros atualizados do modelo de custo incluem as seguintes mudanças:

1. Estender o conjunto de funções integradas adicionando a nova função integrada “serialiseData”.

2. A função integrada “verifySignature” foi renomeada para “verifyEd25519Signature” para deixar mais claro qual é sua função.

3. Recalibrar o modelo de custo para a versão do avaliador no nó para alinhar com as mudanças nos parâmetros de CPU.

Novo Plutus Core integrado

Os tipos integrados e os operadores de tipo permanecem inalterados desde o lançamento do Alonzo. Todas as novas funções integradas são retrocompatíveis. Adicioná-las não quebra nenhum validador de script mais antigo. O lançamento do Vasil continua a suportar as funções integradas do Alonzo e adiciona a seguinte nova função:

serialiseData

Um novo Plutus integrado é adicionado para serializar BuiltinData para BuiltinByteString. A função serialiseData recebe um objeto de dados e o converte em um objeto CBOR.

Plutus já fornece um integrado para hash de estrutura de dados, por exemplo, sha2_256 :: BuiltinByteString -> BuiltinByteString, ele não fornece maneiras genéricas de serializar alguns tipos de dados para BuiltinByteString.

Os custos gerais de memória e CPU são reduzidos tendo um novo integrado para serializar qualquer 'BuiltinData' do Plutus para 'BuiltinByteString' de modo que os validadores possam aproveitar implementações mais otimizadas e construtores de bytestring via integrados do que os disponíveis on-chain.

Para mais explicações, guias práticos e tutoriais, consulte Plutus Docs.

Endereços de script Plutus

Um script Plutus V2 não terá o mesmo valor de hash que um script Plutus V1.

Como os scripts devem corresponder exatamente aos seus hashes on-chain, é importante que os scripts que um aplicativo usa não mudem acidentalmente. Por exemplo, alterar o código-fonte ou atualizar dependências ou ferramentas pode levar a pequenas alterações no script. Como resultado, o hash mudará. Em casos em que os hashes devem corresponder exatamente, mesmo as alterações que não alteram a funcionalidade do script podem ser problemáticas.

Diante dessa consideração, alguns desenvolvedores de DApp podem esperar que ao fazer uma migração de scripts Plutus V1 para scripts Plutus V2, o mesmo código-fonte, ao ser recompilado, gere o mesmo valor de hash desse endereço de script. No entanto, é impossível para um script V2 compilado ter o mesmo hash e endereço de script que um script V1 compilado.

Usar exatamente o mesmo script com diferentes versões de linguagem resultará em hashes diferentes. O mesmo script exato (como em UPLC.Program) pode ser usado como um script Plutus V1 ou um script Plutus V2, e como a versão da linguagem faz parte do hash, os dois hashes serão diferentes.

Um script Plutus V1 não necessariamente terá o mesmo valor de hash ao ser recompilado com uma versão posterior do Compilador Plutus

Suponha que você escreva seu código-fonte Haskell (Plutus Tx), o compile em código Plutus Core (PLC), gere seu valor de hash e o use em uma transação. Se você não salvar seu código compilado e decidir usar o mesmo script no futuro, você teria que recompilá-lo. Isso poderia resultar em um valor de hash diferente do endereço do script mesmo sem atualizar de scripts Plutus V1 para scripts Plutus V2. Isso ocorre porque o hash é calculado com base na saída do código compilado.

Dadas as mudanças na versão do compilador Plutus, mudanças nas dependências e várias outras melhorias, espera-se que o valor de hash do endereço do script mude depois que o código-fonte for recompilado.

Quando exportar e salvar a saída de um script compilado

Assim que você esperar que não modificará a parte on-chain do seu aplicativo e não quiser que o valor de hash do endereço do seu script mude, a melhor maneira de mantê-lo o mesmo é salvar a saída do seu código Plutus Core compilado final (PLC) em um arquivo.

Para detalhes sobre como exportar scripts, consulte: Como exportar scripts, datums e redeemers na documentação do usuário do Plutus Core.

Entradas de referência (CIP-31)

As saídas de transação carregam datums, que permitem acesso a informações na cadeia de blocos. No entanto, esses datums são limitados de várias maneiras. Por exemplo, para acessar informações no datum, você precisaria gastar a saída à qual o datum está anexado. Isso requer a recriação de uma saída gasta. Qualquer usuário que deseje ver os dados não pode gastar a saída antiga (que desapareceu), mas deve gastar a nova saída (que eles não saberão até o próximo bloco). Na prática, isso limita algumas aplicações a uma 'operação' por bloco, diminuindo assim o desempenho desejado.

O CIP-31 introduz um novo mecanismo para acessar informações em datums - uma entrada de referência. As entradas de referência permitem olhar para uma saída sem gastá-la. Isso facilitará o acesso a informações armazenadas na cadeia de blocos sem a necessidade de gastar e recriar saídas de transação não gastas (UTXOs).

O caso de uso principal do CIP-31 é apoiar scripts de referência (CIP-33). Outros casos de uso incluem:

1. Inspeção do estado (datum ou valor bloqueado) de um aplicativo on-chain sem ter que consumir a saída. Por exemplo, verificar o estado atual de uma máquina de estado de stablecoin.
2. A capacidade de referenciar provedores de dados on-chain que armazenam dados em saídas por outros scripts.

Consulte o tutorial de como usar entradas de referência para mais detalhes.

Datums inline (CIP-32)

Datums que carregam informações de transação são comumente implementados anexando hashes de datums a saídas. Isso é bastante inconveniente para os usuários. Datums tendem a representar o resultado da computação feita pela parte que cria a saída, e como tal, há quase nenhuma chance de que a parte gastadora conheça o datum sem se comunicar com a parte criadora. Isso significa que o datum deve ser comunicado entre as partes fora da cadeia ou na cadeia, incluindo-o no mapa de testemunhas da transação que cria a saída ('datums extras'). Tal caso exige que a parte gastadora observe toda a cadeia para encontrar o datum, o que também é inconveniente.

O CIP-32 sugere uma solução que permite que datums em si sejam anexados a saídas em vez de hashes de datums. Isso permitirá uma comunicação muito mais simples de valores de datum entre os usuários.

Os casos de uso incluem:

• Criar um único UTXO com dados a serem usados em várias transações subsequentes, mas pagando apenas o custo para enviá-lo uma vez.
• Armazenar pouca informação on-chain. Por exemplo, Oracles podem se beneficiar disso adicionando simplesmente alguns dados off-chain à cadeia principal.

Consulte o tutorial de como usar datums inline para mais detalhes.

Scripts de referência (CIP-33)

Ao gastar uma saída bloqueada com um script Plutus, você deve incluir o script na transação de gastos. Portanto, o tamanho dos scripts contribui para o tamanho da transação, o que influencia diretamente o throughput do Cardano.

Tamanhos de scripts grandes causam problemas para os usuários porque:

1. Transações maiores resultam em taxas mais altas.
2. As transações têm limites de tamanho. Scripts grandes podem atingir os limites. Mesmo que um script caiba, vários scripts em uma transação podem não caber. Isso torna difícil executar transações complexas que dependem de vários scripts.

O CIP-33 introduz a capacidade de referenciar um script sem incluí-lo em cada transação. Isso reduz drasticamente a contribuição dos scripts para o tamanho da transação.

Consulte o tutorial de como referenciar scripts para mais detalhes.

Resgatadores de transação

Dois elementos importantes no Plutus são datums e resgatadores. O datum é uma informação que pode ser associada a um UTXO e é usado para transportar informações de estado do script. É frequentemente usado em combinação com um resgatador, que é como uma instrução ou comando para o contrato.

Com o hard fork do Vasil, os desenvolvedores poderão ver resgatadores para todas as entradas, em vez de apenas a que está sendo passada para o script atualmente em execução.

Endereço de mudança de garantia

A garantia do script é a garantia monetária que um usuário dá para garantir que a transação que usa um contrato tenha sido cuidadosamente construída e testada antes da submissão aos validadores. É usada para garantir que os nós sejam compensados pelo trabalho em caso de falha na validação da fase 2. O valor da garantia é especificado no momento da construção da transação e é reservado para permitir a execução do script on-chain.

Atualmente, na mainnet do Cardano, o valor da garantia é definido como 150% da taxa de transação, e nenhuma mudança é fornecida para o UTXO de garantia. Isso significa que se um script falhar na validação da fase 2, o usuário do DApp perderá todos os fundos armazenados no UTXO escolhido para a garantia.

Com o hard fork do Vasil, os desenvolvedores de DApp terão a possibilidade de especificar um endereço de mudança para a garantia do script. Isso significa que, caso o script falhe na validação da fase 2, apenas a quantia correta será retirada, e os fundos restantes serão enviados para o endereço de mudança fornecido.

Consulte o tutorial de como usar saídas de garantia para mais detalhes.

Implementação única de VRF

No Cardano, a Função de Aleatoriedade Verificável (VRF) determina qual SPO cria o próximo bloco. Antes do Vasil, havia duas funções VRF executadas em cada salto de rede para validar um bloco. Com o hard fork do Vasil, uma dessas funções é eliminada, resultando em uma validação de bloco mais rápida e tempos de sincronização de rede globais mais rápidos.