Armazenando Dados em transações Nano

Part2: Pay-to-Fake-Key — Gravando 32 bytes dentro de carteiras Nano

No artigo anterior eu mostrei uma técnica de armazenarmos dados nas casas decimais do saldo de micro-transações Nano, portanto criando mensagens imutáveis a custo baixissimo. No entanto, ainda que para pequenas mensagens possa servir bem, gravar mais do que 13 caracteres (em base100) ou 8 bytes (em base85) pode ser economicamente inviável.

Neste artigo irei explicar como gravar até 32 bytes dentro de uma carteira Nano comum, como essa: nano_1idkfoiqnsdge7q8aus1ejipauum63kpta4ge7q8ya4qe7p8rsdnc4qn8ybf

Acredite ou não, aí dentro está escrito “Armazenando dados em Nano Wallet

Trata-se de uma carteira que não tem chave privada, logo não há como gastar o saldo que mandamos pra ela, no entanto ela carrega em sí mesma dados que podem ser úteis e lidos por qualquer um. Simplesmente colocamos bytes personalizados dentro da chave-pública e convertemos pro padrão da carteira Nano.

Primeiro vamos entender, resumidamente, como funcionaria a criação de uma carteira normalmente:

Diagrama simples do processo de geração de contas Nano

É criado, de forma aleatória ou atravéz de uma mnemonic, a “seed”. É como se fosse uma chave mestra pela qual extraímos bilhões de chaves privadas válidas. A partir de cada chave privada, então, extraímos uma chave pública, essa última sim já pode ser compartilhada com outras pessoas, mas isto é feito após ela ser codificada para o formato de carteira Nano, veja a exemplificação da função “Encode in Nano Wallet Format”.

Exemplificação da codificação da chave pública para o formato da carteira Nano

É concatenado o prefix + base32 ( public_key + blake2_checksum(public key))

Logo, para criar uma carteira que você possa usar para transacionar, é preciso gerar primeiro a seed, chave privada. Daí então é extraído a chave pública e convertida para o formato de carteira Nano.

Isto, porém, não ocorre para colocarmos nossos 32 bytes personalizados. Apenas codificamos os 32 bytes diretamente para o formato de carteira Nano

Nosso processo de armazenamento simplifica, usando uma chave pública inválida, com dados personalizados

Não havendo portando chave privada por trás, também não temos como usar esta carteira para gastar, ela apenas pode receber. Pois sem sua chave privada não há como assinar sua transação. Todo saldo que for enviado pra ela ficará lá indefinidamente.

Ainda sim, caso alguém envie algum saldo para tal carteira, a transação estará permanentemente gravada na ledger da Nano e associada a conta de quem transacionou. Mesmo que aquele saldo fique parado lá para sempre, não será remolvido da ledger, pois trata-se de um registro imutável. Assim sendo, qualquer um que quiser ver a suposta chave pública daquela carteira irá deparar-se com os dados que você colocou lá!

Simples, não ?

Prova de Conceito

Eu conheci esse método graças ao Hamilton que apresentou-o na comunidade Nano Brasil ao gravar todo o whitepaper da Nano em transações da mesma!

Anúncio do Hamilton na Comunidade Nano

Primeiro ele converteu todo o texto do whitepaper para o formato de carteiras Nano. Sendo que cada carteira armazena até 32 bytes, precisou de 1152 carteiras para armazenar os 36864 caracteres, 1 caractere para cada byte. Enviou todas transações a partir desta carteira que você pode abrir no explorer: xrb_3bbu364reht9o5ks6buyp348i1hex9e8mryd6eukcxxbnzb1szhhegnn35cg

Carteiras Nano armazenando whitepaper Nano

Parecem carteiras comum, correto ? Porém, se você inserir no console exatamente este código e dar enter, as chaves públicas serão decodificadas para UTF8 diretamente, assim você pode ler todas transações e ver que todas juntas formam o texto do whitepaper da Nano.

Carteiras “decodificadas” de volta para texto, mostrando o whitepaper

Para criar as carteiras ele utilizou este script em Python: https://github.com/jrhaskel/mensage_nano

No total foram gastos apenas 368640 raws, ou seja, 0.000000000000000000000000368640 Nano. Pois usou 10 raws para cada transação, porém poderia ter sido gasto ainda menos, apenas 1 para cada mensagem (ou mesmo zero, pois a Nano suporta este tipo de transação).

Demo online:

Com esta ferramenta web em javascript e html, vocês podem ver funcionando na prática este processo de conversão de texto para carteira Nano e vice-versa: https://anarkrypto.github.io/NanoWalletToText

Basta colocar qualquer texto dentro do box, que automaticaticamente ele converte para várias carteiras Nano. Ou colocar as carteiras Nano com as mensagens codificadas que ele converte de novo para o formato de texto da mensagem (UTF8).

Código: https://github.com/anarkrypto/NanoWalletToText

A idéia é que você pode enviar o saldo informado para esta carteira e ela estará permanentemente associada a sua conta. Simples, não ?

Aperfeiçoando o método: identificando carteiras com mensagens

Então, se entendeu tudo até aqui e também leu o artigo Armazenando Dados em transações Nano, parte 1”, já sabe:

  1. Como gravar pequenas mensagens no campo saldo de transações Nano, usando as casas decimais de micro-transações, podendo gravar 12 caracteres gastando menos de 0.000001 Nano ou 8 bytes gastando menos de 0.0000000001 Nano, por exemplo.
  2. Como gravar até 32 bytes dentro de carteiras Nano, usando chaves públicas “Fake”.

Sendo que com este segundo método podemos mandar apenas 1 raw (0.000000000000000000000000000001 Nano) para cada carteira com os 32 bytes personalizados, fica claro que o mesmo é mais barato e eficiente para armazenar dados, salvando mais e economizando raws. Porém, ele sozinho não é perfeito. Você pode se questionar:

Como saber se tem uma mensagem dentro da carteira ?

Embora carteiras pudessem ser utilizadas exclusivamente para esta finalidade, pode ser útil utilizar uma mesma carteira tanto para pagamento quanto enviar mensagens, então eventualmente pode haver a necessidade de usa-la para fazer transferências. Neste caso não seria possível de saber, apenas olhando as carteiras recebendo, quais tem uma suposta mensagem ou não. Qualquer carteira pode ser convertida de volta para chave pública e representada em utf8. Precisamos de uma forma de identificar as carteiras com dados. Para isto, podemos usar flags.

Vejo duas formas de criarmos estas flags:

  1. Usando os primeiros bytes da carteira para armazenar tal flag, igual exemplificado no artigo anterior (parte1). Exemplo: Toda carteira que começa com “MSG” (em base32) tem uma mensagem no restante da carteira. Funcional, porém podemos poupar estes primeiros bytes, sobrando mais espaço para a mensagem, veja:
  2. Armanzenando as flags dentro do saldo da transação para a carteira com a mensagem, da forma que expliquei no artigo anterior (parte1)! Assim, se por exemplo esta carteira recebeu 455139 raws = 0.000000000000000000000000455139 Nano (a flag “MSG” em base100”), podemos identifica-la automaticamente entre milhões de outras transações que não carregam mensagem! Não estaríamos mais gastando apenas 1 raw, mas o valor continuaria ridiculamente baixo.

Podem haver milhões de flags diferentes, utilizadas para identificar diferentes tipos de mensagens, diferentes tipos de dados e até indices.

Já temos aqui, portanto, um mecanismo eficiente, barato, descentralizado, instantâneo e escalável de enviar mensagens imutáveis entre carteiras Nano. Basta que haja um software cliente analisando todas transações de determinada(s) carteira(s), que ao achar uma com a nossa flag, irá automaticamente converter a carteira codificada de volta para a mensagem que salvamos, para fortmato de texto.

Assim como a técnica explicada na part1, também podemos usar o pay-to-fake-key para criar chats inteiramente armazenados em transações Nano.

Mas aqui obtemos muito mais eficiência com menor custo. Cada conta pode enviar flags (por meio do campo saldo) para as carteiras com as mensagens, todos que seguem ela podem ler tais. Podem haver transações que agem como cabeçalho, informando por exemplo o recepetor desejado e também pode-se usar criptografia. Nas flags ainda pode ser definido os indices para ordenar as mensagens em chunks (parte1, parte2, parte3 e etc..), podendo enviar mensagens gigantes com custo baixissimo. Veja como exemplo o whitepaper gravado pelo Hamilton. Neste caso o desafio continua sendo apenas o PoW das transações.

Quem acompanha a Nano pode saber que no node versão 21.0 é esperado a implementação do pruning, que significa “poda”. Trata-se de uma funcionalidade opcional que, ao criar um resumo das transações de cada conta, diminui o tamanho da ledger, poupando, portanto, espaço de armazenamento.

Como dito, é uma funcionalidade opcional. Ainda haverão os historical nodes, que armazenarão todas transações, integralmente, sem resumir.

Mas, mesmo assim, é importante ressaltar que nem mesmo o pruning pode apagar mensagens gravadas usando esta técnica Pay-to-Fake-Key. Pois o pruning não pode resumir transações que nem sequer foram embolsadas/desbloqueadas pela carteira recebendo. Afinal, como já explicado, a carteira para qual mandamos não tem chave privada… o saldo ficará lá parado para sempre! Então mesmo nodes prunados irão armazenar tais mensagens, não podendo resumi-las ou excluí-las. Uma excelente notícia, não ?

No próximo artigo, part3, mostrarei como usaremos estas técnicas para indexar quaisquer tipos de arquivos, incluindo videos e imagens, dentro de transações Nano! Aguardem…

Gostou ? Curta e compartilhe!

Ajude a financiar o projeto ImagiNano, uma rede social descentralizada e incensurável baseada em Nano e IPFS: nano_3cryi6idukyctxourp7uc14o4t7kgx7eezhqeipo4qrrhnip91pkxi5ej9yf

Mais informações, entre no nosso grupo

Desenvolvedor, cripto-entusiasta e criptolibertário

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store