Serviço de arquivamento de bxid Qubic

O Qubic é muito único e possui características que dificultam a interface direta com grande parte da infraestrutura de criptografia existente. O objetivo desta proposta é definir um hash único, bxid, que representa uma prova confirmada e instantaneamente final de que o valor foi transferido. Uma API indexada por bxid permitiria uma integração muito mais fácil do Qubic com sistemas que esperam um txid de criptografia tradicional confirmada.

O bxid, ID de Transferência de Saldo, pode ser calculado localmente antes de ser incluído em um tick. Isso permite que as carteiras exibam o bxid para os usuários e também consultem um serviço de API para o bxid. Se, após o tick especificado, o bxid não estiver lá, isso significaria que a transação falhou em transferir valor.

No caso normal de transferência QU, o bxid é definido pelo hash K12 de epoch + tick + srcpubkey + destpubkey + amount, em um formato de byte que corresponde à entrada do logfile. Para outros tipos de transações, o bxid pode seguir a mesma convenção hashando a entrada do logfile diretamente. No entanto, certifique-se de pular os campos de data, pois eles não podem ser conhecidos no momento da criação da tx.

O acima funciona para transferências normais devido à restrição de uma transferência normal por tick de um endereço. Há o problema de mudanças de saldo de SC que não têm uma transação e a fonte é apenas o número de SC, sem limites no número de vezes que o destino pode ser pago por tick. Isso levará ao mesmo bxid, já que todos os campos serão os mesmos. Após muita discussão no discord, ficou claro que precisará haver um tratamento especial para essas mudanças de saldo sem transação para manter a unicidade do bxid por mudança de saldo. Minha ideia para isso é calcular as mudanças de saldo de SC com valor 0 para que possa ser calculado. Então a consulta para esse bxid retornaria o valor como a soma de todas as mudanças de saldo para esse destino naquele tick. É verdade que geralmente haveria apenas uma, mas dessa forma um número arbitrário delas pode ser tratado.

Agora existem dois casos para bxid; o caso principal é quando, à medida que as entradas do log para o tick especificado são processadas, ele é adicionado ao banco de dados e então a carteira que enviou a transação consulta a API para ver se o bxid existe. Se existir, isso significa que a transação foi bem-sucedida; se não existir, isso significa que a transação falhou em transferir saldo, mesmo que tenha sido incluída nos dados do tick.

Uma coisa a ter cuidado é que o processamento do log não será exatamente em tempo real, então o serviço da API deve retornar o último tick visto no processamento do log. Podemos saber que, se o tick N foi processado, nenhuma nova entrada de log para ticks menores que N chegará. Portanto, a ausência do bxid após o tick especificado ter sido processado pode ser usada como evidência de falha da transação.

Sobre a questão de provar criptograficamente as informações do bxid fornecidas pelo serviço da API, novamente divide-se em dois casos. O caso fácil é quando o bxid existe; nesse caso, o txid correspondente pode ser encontrado no tick incluído e usando os métodos usuais, validar a transação como válida. O segundo caso, onde o txid foi incluído no tick, mas o bxid está ausente, exigirá um pouco mais de trabalho para validar criptograficamente.

Primeiro, as informações da entidade precisam ser validadas para obter o saldo atual. Então, todos os bxid para a epoch para o endereço específico são somados e subtraídos com base na fonte ou destino. Essa mudança líquida então adicionada ao início do arquivo de espectro epoch gerará um saldo baseado no bxid. Se isso corresponder ao saldo usando os dados da entidade que foram validadas criptograficamente, podemos ver que o bxid chegou ao mesmo saldo.

Agora podemos passar para o lado da implementação do serviço de arquivamento de bxid. Uma vez que isso esteja funcionando e disponível publicamente, irá simplificar dramaticamente a integração de serviços externos.

Eu fiz uma prova de conceito funcional em qubic-cli/bxid.cpp no main · Qsilver97/qubic-cli (github.com)

Ele suporta duas funções, criando um bxid a partir de detalhes da transação e a geração de saída JSON a partir das entradas do logfile do qubic. Nós precisamos configurar fullnodes específicas para gerar logfiles e fornecer serviço a clientes específicos protegidos por senhas. O meu release permite que qualquer um com acesso aos logfiles crie um serviço de arquivamento de bxid e, claro, o estenda com outros campos JSON desejados.

Exemplo de JSON criado a partir de uma entrada de logfile:

{ “index” : { “_index”: “bxid”, “_id” : “397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190” } }{“utime”:”1707059413", “epoch”:”90", “tick”:”11867469", “type”:”1", “src”:”LZLDOEIBQWIUGGMZGOISLOAACDGAFVAMAYXSSJMLQBHSHWDBPMSDFTGAYRMN”, “dest”:”QHQPMJVNGZJGZDSQREFXHHAZFYPBIYDOTFAOTTWGYCWGTIRNGBVMKBGGNDDA”, “amount”: “1521139” }

{ “index” : { “_index”: “bxid”, “_id” : “397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190” } }{“utime”:”1707059413", “epoch”:”90", “tick”:”11867469", “type”:”1", “src”:”LZLDOEIBQWIUGGMZGOISLOAACDGAFVAMAYXSSJMLQBHSHWDBPMSDFTGAYRMN”, “dest”:”QHQPMJVNGZJGZDSQREFXHHAZFYPBIYDOTFAOTTWGYCWGTIRNGBVMKBGGNDDA”, “amount”: “1521139” }

{ “index” : { “_index”: “bxid”, “_id” : “397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190” } }{“utime”:”1707059413", “epoch”:”90", “tick”:”11867469", “type”:”1", “src”:”LZLDOEIBQWIUGGMZGOISLOAACDGAFVAMAYXSSJMLQBHSHWDBPMSDFTGAYRMN”, “dest”:”QHQPMJVNGZJGZDSQREFXHHAZFYPBIYDOTFAOTTWGYCWGTIRNGBVMKBGGNDDA”, “amount”: “1521139” }

Estas são as duas linhas necessárias como entrada pelo sistema charmed opensearch. Isso pode ser instalado seguindo Charmhub

Depois disso, magicamente obtemos um serviço de API REST! Documentação OpenSearch

A melhor parte é que um simples loop de processamento de log criará o serviço de arquivamento com a interface REST acima que permite consultas por qualquer campo, bxid, fonte, destino, até mesmo tick ou epoch usando curl.

curl — cacert demo-ca.pem -XGET https://<username>:<password>@<ipaddr>:9200/bxid/_doc/397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190{“_index”: “bxid”,“_id”: “397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190”,“_version”: 2,“_seq_no”: 32754,“_primary_term”: 1,“found”: true,“_source”: {“utime”: “1707059413”,“epoch”: “90”,“tick”: “11867469”,“type”: “1”,“src”: “LZLDOEIBQWIUGGMZGOISLOAACDGAFVAMAYXSSJMLQBHSHWDBPMSDFTGAYRMN”,“dest”: “QHQPMJVNGZJGZDSQREFXHHAZFYPBIYDOTFAOTTWGYCWGTIRNGBVMKBGGNDDA”,“amount”: “1521139”}}

curl — cacert demo-ca.pem -XGET https://<username>:<password>@<ipaddr>:9200/bxid/_doc/397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190{“_index”: “bxid”,“_id”: “397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190”,“_version”: 2,“_seq_no”: 32754,“_primary_term”: 1,“found”: true,“_source”: {“utime”: “1707059413”,“epoch”: “90”,“tick”: “11867469”,“type”: “1”,“src”: “LZLDOEIBQWIUGGMZGOISLOAACDGAFVAMAYXSSJMLQBHSHWDBPMSDFTGAYRMN”,“dest”: “QHQPMJVNGZJGZDSQREFXHHAZFYPBIYDOTFAOTTWGYCWGTIRNGBVMKBGGNDDA”,“amount”: “1521139”}}

curl — cacert demo-ca.pem -XGET https://<username>:<password>@<ipaddr>:9200/bxid/_doc/397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190{“_index”: “bxid”,“_id”: “397e947847ada93de80907d88a835419fb532b3ca1fd68b3c95ebab11cd24190”,“_version”: 2,“_seq_no”: 32754,“_primary_term”: 1,“found”: true,“_source”: {“utime”: “1707059413”,“epoch”: “90”,“tick”: “11867469”,“type”: “1”,“src”: “LZLDOEIBQWIUGGMZGOISLOAACDGAFVAMAYXSSJMLQBHSHWDBPMSDFTGAYRMN”,“dest”: “QHQPMJVNGZJGZDSQREFXHHAZFYPBIYDOTFAOTTWGYCWGTIRNGBVMKBGGNDDA”,“amount”: “1521139”}}