O roteiro do Ethereum inicialmente tinha duas estratégias de escalabilidade: sharding e protocolos Layer 2. Essas duas estratégias acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade do Ethereum até hoje.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: Ethereum L1 se concentra em ser uma camada base poderosa e descentralizada, enquanto L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é onipresente na sociedade: a existência do sistema judicial (L1) é para proteger contratos e propriedades, enquanto os empreendedores (L2) constroem sobre essa base, impulsionando a humanidade para frente.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e vários EVM Rollups passaram para a primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica, e a diversidade e pluralidade na implementação de partições tornaram-se uma realidade. No entanto, seguir este caminho também apresenta alguns desafios únicos. Portanto, a nossa tarefa agora é completar o roteiro centrado em Rollup, resolver esses problemas, ao mesmo tempo em que mantemos a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos-chave
No futuro, o Ethereum poderá alcançar mais de 100 mil TPS através do L2;
Manter a descentralização e robustez do L1;
Pelo menos algumas L2 herdam completamente as propriedades centrais do Ethereum ( de confiança, abertura e resistência à censura );
Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.
Conteúdo deste capítulo
O paradoxo do triângulo de escalabilidade
Avanços adicionais na amostragem de disponibilidade de dados
Compressão de dados
Plasma Generalizado
Sistema de prova L2 maduro
Melhoria da interoperabilidade entre L2
Expandir execução no L1
Paradoxo da Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre três características da blockchain: descentralização (, custo baixo dos nós de execução ), escalabilidade (, que envolve um grande número de transações processadas ), e segurança (, onde um atacante precisaria comprometer uma grande parte dos nós na rede para causar a falha de uma única transação ).
É importante notar que o paradoxo do triângulo não é um teorema, e as postagens que introduzem o paradoxo do triângulo também não incluem prova matemática. Ele apresenta um argumento matemático heurístico: se um nó amigável à descentralização pode validar N transações por segundo, e você tem uma cadeia que pode processar k*N transações por segundo, então (i) cada transação só pode ser vista por 1/k nós, o que significa que um atacante precisa apenas comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza. O objetivo deste artigo nunca foi provar que quebrar o paradoxo do triângulo é impossível; em vez disso, ele visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair do quadro mental implícito no argumento.
Ao longo dos anos, algumas cadeias de alto desempenho frequentemente afirmam ter resolvido o triângulo das Bermudas sem alterar fundamentalmente a sua arquitetura, geralmente aplicando técnicas de engenharia de software para otimizar nós. Isso é sempre enganador, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum. Este artigo irá explorar por que isso acontece e por que apenas a engenharia de software dos clientes L1 não pode escalar o Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo do triângulo: permite que os clientes verifiquem uma certa quantidade de dados como disponíveis, e que uma certa quantidade de passos de cálculo sejam executados corretamente, com o download de apenas uma pequena quantidade de dados e a execução de um número muito reduzido de cálculos. Os SNARKs são sem confiança. A amostragem de disponibilidade de dados possui um modelo de confiança sutil de few-of-N, mas mantém as características fundamentais de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceites pela rede.
Outra forma de resolver o dilema das três zonas é a arquitetura Plasma, que utiliza técnicas inteligentes para transferir a responsabilidade pela disponibilidade dos dados de monitoramento para os usuários, de uma forma compatível com incentivos. Entre 2017 e 2019, quando tínhamos apenas a prova de fraude como meio de expandir a capacidade computacional, a Plasma era muito limitada em termos de execução segura, mas com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais viável para uma gama de casos de uso mais ampla do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Estamos a resolver que problema?
No dia 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de cerca de 125 kB em cada slot de 12 segundos, ou uma largura de banda de dados disponível de cerca de 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o TPS máximo do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do calldata do Ethereum (: cada slot 30 milhões de Gas / por byte 16 gas = cada slot 1.875.000 bytes ), isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma grande melhoria para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, se combinado com melhorias na compressão de dados Rollup, isso trará ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "amostragem 1D". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo primo de 253 bits. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação de 16 coordenadas adjacentes dentre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, quaisquer 4096 ( de acordo com os parâmetros propostos atualmente: quaisquer 64 de 128 amostras possíveis ) podem recuperar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob, e solicita aos pares na rede p2p global ( quem irá escutar diferentes sub-redes ) para obter os blobs necessários em outras sub-redes. A versão mais conservadora SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível dos pares. A proposta atual é que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto os outros nós (, ou seja, os clientes ), utilizem o PeerDAS.
Teoricamente, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256( com um objetivo de 128), então podemos alcançar um objetivo de 16MB, onde a amostragem de disponibilidade de dados em cada nó tem 16 amostras * 128 blobs * 512 bytes por amostra por blob = 1 MB de largura de banda de dados por slot. Isso está apenas no limite da nossa tolerância: é viável, mas significa que clientes com largura de banda limitada não podem amostrar. Podemos otimizar isso até certo ponto reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentaria o custo de reconstrução.
Portanto, queremos ir mais longe e realizar amostragem 2D, um método que não só realiza amostragem aleatória dentro do blob, mas também entre blobs. Utilizando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija um blob, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem blocos só precisam ter o compromisso KZG do blob, e podem confiar na amostragem de disponibilidade de dados para verificar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional também é essencialmente amigável à construção de blocos distribuídos.
O que mais precisa ser feito? Quais são as compensações?
A próxima etapa é completar a implementação e o lançamento do PeerDAS. Depois, aumentaremos constantemente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança; este é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS, bem como suas interações com questões de segurança, como regras de escolha de fork.
Em fases futuras mais distantes, precisaremos fazer mais trabalho para determinar a versão ideal do 2D DAS e demonstrar suas propriedades de segurança. Também esperamos, em última análise, ser capazes de passar do KZG para uma alternativa quântica segura e sem configuração confiável. Atualmente, não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo usando a cara tecnologia de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log(n) * log(log(n)) hashes( usando STIR), na prática, um STARK é quase do tamanho de todo o blob.
O caminho de realidade a longo prazo que eu considero é:
Implementar o DAS 2D ideal;
Manter o uso de 1D DAS, sacrificando a eficiência da largura de banda de amostragem, para aceitar um limite de dados mais baixo em prol da simplicidade e robustez.
Abandonar o DA e aceitar completamente o Plasma como a nossa principal arquitetura Layer2 de interesse.
Por favor, note que, mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda existe. Isso porque, se a camada L1 tiver que lidar com um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão uma maneira eficiente de validar sua correção. Portanto, teremos que usar na camada L1 a mesma tecnologia que o Rollup(, como ZK-EVM e DAS).
Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS será reduzida, ou pelo menos adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente favorável à reconstrução distribuída, na prática, isso precisa ser combinado com a proposta da lista de inclusão de pacotes e os mecanismos de escolha de bifurcação ao seu redor.
Compressão de Dados
Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Para cada slot de 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos não apenas resolver o problema dos numeradores, mas também resolver o problema dos denominadores, permitindo que cada transação em um Rollup ocupasse menos bytes na cadeia?
O que é isso, como funciona?
Na compressão de bytes zeros, substituímos cada sequência longa de bytes zeros por dois bytes, representando quantos bytes zeros existem. Mais além, utilizamos propriedades específicas das transações:
Agregação de assinaturas: Mudamos de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, que pode provar a validade de todas as assinaturas originais. Na camada L1, devido ao alto custo computacional de verificação mesmo com agregação, não consideramos o uso de assinaturas BLS. Mas em um ambiente L2, onde os dados são escassos, faz sentido usar assinaturas BLS. A característica de agregação do ERC-4337 oferece um caminho para realizar essa funcionalidade.
Substituir endereços por ponteiros: Se já utilizou um determinado endereço anteriormente, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma posição em histórico.
Serialização personalizada do valor da transação ------ A maioria dos valores de transação tem poucos dígitos, por exemplo, 0,25 Éter é representado como 250
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
22 Curtidas
Recompensa
22
4
Compartilhar
Comentário
0/400
BrokeBeans
· 07-22 21:16
Ainda a fazer amplificação de dados? Já está tudo gasto.
Ver originalResponder0
BearMarketSurvivor
· 07-22 21:15
A linha de suprimentos na retaguarda está muito estável, a força de combate do Ethereum continua a aumentar.
Ethereum em expansão: Análise da estratégia de escalabilidade The Surge e objetivos futuros
The Surge: O futuro da escalabilidade do Ethereum
O roteiro do Ethereum inicialmente tinha duas estratégias de escalabilidade: sharding e protocolos Layer 2. Essas duas estratégias acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade do Ethereum até hoje.
O roteiro centrado em Rollup propõe uma divisão de trabalho simples: Ethereum L1 se concentra em ser uma camada base poderosa e descentralizada, enquanto L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é onipresente na sociedade: a existência do sistema judicial (L1) é para proteger contratos e propriedades, enquanto os empreendedores (L2) constroem sobre essa base, impulsionando a humanidade para frente.
Este ano, o roteiro centrado em Rollup alcançou resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e vários EVM Rollups passaram para a primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica, e a diversidade e pluralidade na implementação de partições tornaram-se uma realidade. No entanto, seguir este caminho também apresenta alguns desafios únicos. Portanto, a nossa tarefa agora é completar o roteiro centrado em Rollup, resolver esses problemas, ao mesmo tempo em que mantemos a robustez e a descentralização do Ethereum L1.
The Surge: Objetivos-chave
Conteúdo deste capítulo
Paradoxo da Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre três características da blockchain: descentralização (, custo baixo dos nós de execução ), escalabilidade (, que envolve um grande número de transações processadas ), e segurança (, onde um atacante precisaria comprometer uma grande parte dos nós na rede para causar a falha de uma única transação ).
É importante notar que o paradoxo do triângulo não é um teorema, e as postagens que introduzem o paradoxo do triângulo também não incluem prova matemática. Ele apresenta um argumento matemático heurístico: se um nó amigável à descentralização pode validar N transações por segundo, e você tem uma cadeia que pode processar k*N transações por segundo, então (i) cada transação só pode ser vista por 1/k nós, o que significa que um atacante precisa apenas comprometer alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza. O objetivo deste artigo nunca foi provar que quebrar o paradoxo do triângulo é impossível; em vez disso, ele visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair do quadro mental implícito no argumento.
Ao longo dos anos, algumas cadeias de alto desempenho frequentemente afirmam ter resolvido o triângulo das Bermudas sem alterar fundamentalmente a sua arquitetura, geralmente aplicando técnicas de engenharia de software para otimizar nós. Isso é sempre enganador, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum. Este artigo irá explorar por que isso acontece e por que apenas a engenharia de software dos clientes L1 não pode escalar o Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo do triângulo: permite que os clientes verifiquem uma certa quantidade de dados como disponíveis, e que uma certa quantidade de passos de cálculo sejam executados corretamente, com o download de apenas uma pequena quantidade de dados e a execução de um número muito reduzido de cálculos. Os SNARKs são sem confiança. A amostragem de disponibilidade de dados possui um modelo de confiança sutil de few-of-N, mas mantém as características fundamentais de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceites pela rede.
Outra forma de resolver o dilema das três zonas é a arquitetura Plasma, que utiliza técnicas inteligentes para transferir a responsabilidade pela disponibilidade dos dados de monitoramento para os usuários, de uma forma compatível com incentivos. Entre 2017 e 2019, quando tínhamos apenas a prova de fraude como meio de expandir a capacidade computacional, a Plasma era muito limitada em termos de execução segura, mas com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais viável para uma gama de casos de uso mais ampla do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Estamos a resolver que problema?
No dia 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de cerca de 125 kB em cada slot de 12 segundos, ou uma largura de banda de dados disponível de cerca de 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o TPS máximo do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o valor máximo teórico do calldata do Ethereum (: cada slot 30 milhões de Gas / por byte 16 gas = cada slot 1.875.000 bytes ), isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma grande melhoria para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, se combinado com melhorias na compressão de dados Rollup, isso trará ~58000 TPS.
O que é isso? Como funciona?
PeerDAS é uma implementação relativamente simples de "amostragem 1D". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo primo de 253 bits. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação de 16 coordenadas adjacentes dentre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, quaisquer 4096 ( de acordo com os parâmetros propostos atualmente: quaisquer 64 de 128 amostras possíveis ) podem recuperar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob, e solicita aos pares na rede p2p global ( quem irá escutar diferentes sub-redes ) para obter os blobs necessários em outras sub-redes. A versão mais conservadora SubnetDAS utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível dos pares. A proposta atual é que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto os outros nós (, ou seja, os clientes ), utilizem o PeerDAS.
Teoricamente, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256( com um objetivo de 128), então podemos alcançar um objetivo de 16MB, onde a amostragem de disponibilidade de dados em cada nó tem 16 amostras * 128 blobs * 512 bytes por amostra por blob = 1 MB de largura de banda de dados por slot. Isso está apenas no limite da nossa tolerância: é viável, mas significa que clientes com largura de banda limitada não podem amostrar. Podemos otimizar isso até certo ponto reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentaria o custo de reconstrução.
Portanto, queremos ir mais longe e realizar amostragem 2D, um método que não só realiza amostragem aleatória dentro do blob, mas também entre blobs. Utilizando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.
É crucial que a expansão do compromisso de cálculo não exija um blob, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem blocos só precisam ter o compromisso KZG do blob, e podem confiar na amostragem de disponibilidade de dados para verificar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional também é essencialmente amigável à construção de blocos distribuídos.
O que mais precisa ser feito? Quais são as compensações?
A próxima etapa é completar a implementação e o lançamento do PeerDAS. Depois, aumentaremos constantemente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança; este é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalhos acadêmicos para regulamentar o PeerDAS e outras versões do DAS, bem como suas interações com questões de segurança, como regras de escolha de fork.
Em fases futuras mais distantes, precisaremos fazer mais trabalho para determinar a versão ideal do 2D DAS e demonstrar suas propriedades de segurança. Também esperamos, em última análise, ser capazes de passar do KZG para uma alternativa quântica segura e sem configuração confiável. Atualmente, não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo usando a cara tecnologia de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log(n) * log(log(n)) hashes( usando STIR), na prática, um STARK é quase do tamanho de todo o blob.
O caminho de realidade a longo prazo que eu considero é:
Por favor, note que, mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda existe. Isso porque, se a camada L1 tiver que lidar com um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão uma maneira eficiente de validar sua correção. Portanto, teremos que usar na camada L1 a mesma tecnologia que o Rollup(, como ZK-EVM e DAS).
Como interagir com outras partes do roteiro?
Se a compressão de dados for implementada, a demanda por 2D DAS será reduzida, ou pelo menos adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente favorável à reconstrução distribuída, na prática, isso precisa ser combinado com a proposta da lista de inclusão de pacotes e os mecanismos de escolha de bifurcação ao seu redor.
Compressão de Dados
Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Para cada slot de 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos não apenas resolver o problema dos numeradores, mas também resolver o problema dos denominadores, permitindo que cada transação em um Rollup ocupasse menos bytes na cadeia?
O que é isso, como funciona?
Na compressão de bytes zeros, substituímos cada sequência longa de bytes zeros por dois bytes, representando quantos bytes zeros existem. Mais além, utilizamos propriedades específicas das transações:
Agregação de assinaturas: Mudamos de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, que pode provar a validade de todas as assinaturas originais. Na camada L1, devido ao alto custo computacional de verificação mesmo com agregação, não consideramos o uso de assinaturas BLS. Mas em um ambiente L2, onde os dados são escassos, faz sentido usar assinaturas BLS. A característica de agregação do ERC-4337 oferece um caminho para realizar essa funcionalidade.
Substituir endereços por ponteiros: Se já utilizou um determinado endereço anteriormente, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma posição em histórico.
Serialização personalizada do valor da transação ------ A maioria dos valores de transação tem poucos dígitos, por exemplo, 0,25 Éter é representado como 250