Armazenando Dados em transações Nano
Part1: Usando o saldo de microtransações para gravar mensagens imutáveis!
A Nano é uma criptomoeda focada em transações instantâneas, taxa zero, com uma rede escalável. Isso torna ela uma criptomoeda muito eficiente para uso no dia-a-dia. Mas tudo que a Nano faz é transacionar saldo de uma carteira para outra. Não é possível gravar mensagens nela da mesma forma que pode ser feito no Bitcoin (OP_RETURN pode gravar 80 bytes por transação). Isso limita seu potencial.
Porém, recentemente descobri que podemos “hackear” o sistema de 3 formas diferentes, colocando desde poucos caracteres até indexar imagens, videos e etc.
O objetivo deste artigo é mostrar-lhes estas 3 formas, em 3 parte diferentes. Esta é a parte 1.
Armazenando caracteres ou bytes dentro do saldo
Além das vantagens já mencionadas, a Nano também suporta verdadeiras micro-transações. Trata-se de um impressionante número de 30 casas decimais após a vírgula.
A menor unidade de Nano é 1 Raw:
1 Raw = 0.000000000000000000000000000001 Nano
Ou seja, 1 Nano = 1 NONILHÃO de Raws (10³⁰ raws). Logo, você pode enviar até 1 NONILHÃO de números diferentes gastando até 1 Nano.
Ou então, caso queira economizar, você pode enviar até 1 trilhão de números diferentes gastando 0.000000000000000001 Nano
Sendo que trata-se de um valor que será armazando num tipo de blockchain descentralizada e incensurável, isso pode ser um interessante sistema de comunicação. Cada número sozinho poderia representar um sinal, um comando, um símbolo ou uma palavra. Mas podemos ir além!
Que tal representar caracteres de forma numérica ? Podemos armazenar 1 caractere a cada 2 casas decimais, por exemplo usando base64, base85 ou outro.. Vamos focar aqui em tentar representar caracteres ASCII.
Bem, 1 casa decimal vai de 0 a 9, temos 10 possíveis números
2 casas decimais vai de 00 a 99 , temos 100 possíveis números.
Pensando nisso, para o melhor aproveitamento, desenvolvi um mecanismo de codificação simples que chamo de BASE100. Ele usa os 94 últimos caracteres da tabela ASCII (exceto DEL)+ 6 outros (ÃÉÇãéç)
Veja a tabela BASE100 abaixo:
Neste caso, se quisessemos escrever “Hello World” de forma numerica, teriamos: 40 68 75 75 78 00 55 78 81 75 67
Podemos, então, armazenar este valor num saldo de exatos: 4068757578005578817567 raw
Convertendo pra megaNano: 0.000000004068757578005578817567 Nano
Bastaria enviar este valor para uma carteira programada para ler estes valores em base100 e pronto! Você estaria mandando mensagens atravéz de transações Nano! Mensagens imutáveis, acessíveis por todo o mundo, verificaveis por qualquer um!
E ainda, claro, tendo um gasto ridiculamento baixo. Na cotação atual (16/08/2019, 1 Nano = 1 USD), o gasto do “Hello World” equivaleria a 0.0000004068757578005578817567 cents de dólar! Mesmo que a Nano chegasse a valer mil dólares, você gastaria em torno de 0.0004 cents!
Com apenas 1 cent em Nano (~0.01 Nano) você poderia mandar mais de 2.4 milhões mensagens deste mesmo tamanho.
Quer ver isto na prática ? Desenvolvi um chat que usa exatamente esse mecanismo para armazenar mensagens dentro de transações Nano: NanoChat (PoC): http://nanochat0.000webhostapp.com (Demo)
Código: https://github.com/anarkrypto/nanochat
Com ele você pode enviar mensagens de diferentes tamanhos. Quanto maior a mensagem, maior o gasto. A carteira que recebe a mensagem, também recebe o saldo. Então todas mensagens serão consideradas doações. Aproveite pra mandar grandes mensagens 😉😏.
Esse é apenas um Proof of Concept, provando o mecanismo
Ok, mas e quando a transação não for uma mensagem, como saber ?
Alguém prestando atenção pode lembrar que a carteira recebendo as mensagens em algum momento pode receber uma transação comum, ao invéz de uma mensagem. E ainda sim, poderia ser tratada como se fosse uma mensagem, representando em base100. Você até pode verificar isso no NanoChat
Para resolver este problema, temos 2 alternativas:
- Podemos utilizar apenas as últimas casas decimais, por exemplo as 18 ou 24 últimas, afinal atualmente quase nenhuma carteira Nano usa essas casas decimais. A Natrium, por exemplo, não envia ou recebe mais que 6 casas decimais após a virgula (0,000001 Nano = 0,0001 cent na cotação atual), pois dificilmente alguem enviaria um valor menor que isso. Sobram-se neste caso até 24 casas decimais para armazenarmos 12 caracteres em base100. No entanto isso não impede o recebimento de “mensagens não intencionais” de outras carteiras que suportam micro-transações.
- Podemos utilizar uma “flag” antes da mensagem, para identifica-la como tal. Exemplos:
“MSG” (45 51 39), nesse caso teríamos 6 casas decimais a menos. Porém a chance de termos tal valor acidentalmente é, literalmente, 1 em 1 milhão (10⁶)
“MS” (45 51), para economizar casas decimais podemos abreviar ao máximo, por exemplo usando apenas 2 caracteres (4 casas decimais). Porém isso aumenta a chance de mensagens acidentais para 1 em 10000 (10⁴)
Veja um exemplo:
O software client programado para ler as mensagens estaria seguindo todas transações enviadas para determinado(s) endereço(s). Ao deparar-se com uma transação que começasse com a flag combinada, ele trataria os valores após ela como uma mensagem, convertendo para base100.
E se eu quiser enviar bytes ou mais opções de caracteres ?
Bem, você pode usar outro método de encode para os dados.
Sendo que 1 byte = 2⁸ = 256 possiveis numeros diferentes, então você precisaria representar de outra forma, usando mais casas decimais. Uma forma simples, porém nada eficiente, seria usar 3 casas decimais para representar cada byte. Embora 3 casas decimais suportem de 000 a 999, só seria usado de 000 a 255.
Uma forma mais eficiente seria utilizando base85. Com ela pode-se armazenar até 4 bytes a cada 5 caraceteres, portanto “é mais eficiente que o uuencode ou Base64, que usa 4 caracteres para representar 3 bytes de dados”. Há um ganho de 1/3 em relação a base64. Então, com base85 podemos armazenar 4 bytes a cada 10 casas decimais, sendo que usamos 2 casas decimais para representar cada caractere.
Logo, você pode armazenar até 4 bytes gastando menos de 0.00000000000000000001 Nano
8 bytes gastando menos de 0.0000000001 Nano
12 bytes gastando menos de 1 Nano (Máximo de 0.999999999999…)
Armazenar grandes mensagens sai muito caro, o que fazer ?
Certamente não vale a pena armazenar muitos caracteres numa única transação. Se você quisesse armazenar 15 caracteres, por exemplo, gastaria até quase 1 Nano. 16 caracteres então… seriam até 100 Nano! 17 seriam até 10000 Nano e assim por diante. Inviável. No entanto, é interessante ressaltar que é possível contornar de outra forma, mesmo sendo algo pouco eficiente, talvez haja certos usos.
Uma possível solução seria dividir sua mensagem em pequenas partes (chunks) e envia-las uma a uma em diferentes transações, todas identificadas com uma flag especifica + o número índice. Por exemplo, considere a mensagem:
“Aqui introduzimos Nano, uma criptomoeda com uma arquitetura original denominada block-lattice, onde cada conta possui sua própria blockchain, possibilitando transações quase instantâneas e escalabilidade ilimitada.”
Podemos representa-la dentro de diversas micro-transações como estas:
“MSG01Aqui int” = 455139013380847200727783 raw
“MSG02roduzimo” = 455139028178678489727678 raw
“MSG03s Nano, ” = 455139038200466477781200 raw
“MSG04uma crip” = 455139048476640066817279 raw
“MSG05tomoeda ” = 455139058378767868676400 raw
“MSG06com uma ” = 455139066678760084766400 raw
“MSG07arquitet” = 455139076481808472836883 raw
“MSG08ura orig” = 455139088481640078817270 raw
E assim por diante…
No total serão necessários 28 transações. Mas seriam gastos menos de 0.0000128 Nano. E nada impede o receptor deenviar esse saldo novamente para o emissor posteriormente.
Usamos apenas 24 casas decimais para cada chunk, constituindo-se da seguinte maneira: A flag “MSG” em BASE100 para indicar a mensagem + o indice da mensagem (que pode usar a propria casa decimal do saldo, sem codificar pra base100) + a mensagem em base100.
Pode-se estabelecer um numero padrão de indices suportados para evitar confudir o indice com a mensagem. Caso o protocolo use um indice variável, o emissor da mensagem pode especificar o tamanho da mensagem anteriormente com uma transação contendo uma espécie de cabeçalho, com o tamanho de índice que usará.
Caso queira enviar outras mensagens para o mesmo receptor, é importante que haja uma comunicação de ambas as partes. Para garantir que o receptor não confundirá os indices da nova mensagem com os indices da ultima, pode por exemplo esperar pelas transações serem embolsadas (unpocketed transaction). Somente após isso o emissor manda a nova mensagem.
Caso ao invéz dos caracteres ASCII contidos na base100 fosse necessário armazenar bytes, apenas usaria-se base85 no lugar, limitando cada chunk de mensagem para 4 bytes (10 casas decimais) ou 8 bytes (20 casas decimais), fora a flag + indice.
Vale ressaltar que esse método não é muito viável, pois muitas transações exigem também muito PoW, o que tornaria o processo demorado. Além de exigir muitas transações ocupando espaço da ledger. Por outro lado é uma forma de armazenar dados permanentemente e praticamente gratuitamente, onchain.
Nos próximos artigos mostrarei formas mais eficientes de fazermos este trabalho.
Conclusão:
Aqui aprendemos a gravar pequenas mensagens/dados em transações Nano, representando caracteres/bytes numericamente no campo de saldo transacionado, gastando quantias irrelevantes para pequenas mensagens, graças ao grande número de casas decimais que a Nano suporta.
Estas mensagens estarão inevitavelmente ligadas a conta do emissor (garantindo autenticidade criptograficamente) e do receptor, e são imutáveis/incensuráveis/indeletáveis, graças ao mecanismo descentralizado da criptomoeda Nano.
Vale lembrar que esse sistema certamente não é apropriado suficientemente para uma comunicação mais completa e sofisticada, como um verdadeiro chat… porém em casos especificos podemos dividir a mensagem em chunks, tendo como desafio principal os múltiplos PoW das transações.
Talvez seu uso mais ideal seja para gravar pequenas informações, talvez labels, flags e etc. Também é possível utilizar como uma forma de emitir comandos para sistemas, dispositivos (IoT Aguardem-nos!).
Nos próximos artigos:
Na parte 2 deste artigo iremos aprender a como gravar 32 bytes dentro do endereço da carteira.
Na parte 3 aprenderemos como indexar arquivos de tamanho ilimitado, como imagens, videos e etc em transações Nano e como podemos usar isto em uma rede social totalmente descentralizada, instantanea e escalável.
Aguardem…
Gostou? Compartilhe!
Ajude a incentivar o projeto da rede social: nano_3cryi6idukyctxourp7uc14o4t7kgx7eezhqeipo4qrrhnip91pkxi5ej9yf
