Os leitores que já sabem que uma GPU pode treinar ou executar um modelo ainda têm de distinguir três modelos: trabalho que cria o bloco, trabalho que os validadores avaliam e trabalho pelo qual um comprador paga. Pearl enquadra-se no primeiro modelo. Uma pontuação ou um aluguer ainda pode ser útil para um comprador, enquanto a cadeia anfitriã continua a produzir blocos sem esse trabalho da GPU.
Um trabalho aprovado, uma pontuação elevada atribuída pelos validadores e uma resposta vencedora de um tile respondem a perguntas diferentes. O preço e a disponibilidade não colocam uma rede no mesmo modelo.
A Pearl é uma blockchain de camada 1 cuja unidade de trabalho é a multiplicação de matrizes numa GPU. O whitepaper Pearl INT especifica um modelo de prova de trabalho útil no qual essa multiplicação também pode servir como prova do bloco. O minerador escolhe as matrizes, e os tiles do produto funcionam como bilhetes de lotaria. O minerador que encontra um bilhete vencedor publica o bloco e recebe o pagamento em PRL. Na Gate, o símbolo de mercado à vista desse ativo nativo é PEARL.
A Bittensor é uma rede aberta de sub-redes. Os mineradores produzem um recurso, como computação, inferência, armazenamento ou previsões. Os validadores avaliam os mineradores através da definição de pesos, e o Yuma Consensus agrega esses pesos em vez de avaliar diretamente o trabalho. Os criadores das sub-redes definem o incentivo, os stakers apoiam os validadores com TAO e a cadeia paga TAO com base nesse agregado. Uma pontuação elevada é uma avaliação segundo o incentivo dessa sub-rede, não uma regra segundo a qual um produto de matrizes tem de ser a pré-imagem do bloco seguinte.
A Akash Network é um marketplace de computação em contentores, desenvolvido com o Cosmos SDK e o CometBFT. Um cliente descreve a CPU, a memória, o armazenamento e, quando disponível, a GPU num ficheiro de implementação. Os fornecedores apresentam propostas, o cliente aceita uma proposta e a cadeia regista um aluguer. A prova de participação delegada seleciona os validadores da Akash. A GPU que executa o contentor é o produto alugado, não o puzzle que esses validadores resolvem.
A Render Network atribui trabalhos de GPU, sobretudo de renderização e de computação relacionada, a operadores de nós. O RENDER é um ativo SPL na Solana. Um criador queima RENDER para obter créditos de trabalho que permitem submeter um trabalho, e os operadores de nós são pagos através de um calendário de emissões separado, e não através dos tokens queimados. Os validadores da Solana produzem blocos da Solana. A liquidação de um trabalho atualiza o registo de trabalho da Render, não a lotaria de blocos da Solana.
Entre estas quatro redes, o trabalho útil só produz o bloco no modelo da Pearl. Os mineradores da Pearl procuram um tile cujo hash cumpra o objetivo de dificuldade. Essa procura é a prova de trabalho. Repetir essas multiplicações até um tile ganhar é o que torna dispendiosa a produção de uma história concorrente.
As outras três podem prestar um serviço a um comprador e, ainda assim, manter a produção de blocos noutro local. A Bittensor paga pelo que quer que uma sub-rede defina, e o TAO segue os pesos agregados pelo Yuma. A Akash paga um contentor ao abrigo de um aluguer. A Render paga por um trabalho concluído. Essas cadeias podem continuar a produzir blocos se o mercado de GPU ficar inativo: a cadeia da Bittensor utiliza prova de autoridade, a Akash e a Solana utilizam staking e nenhuma das três utiliza o trabalho da GPU como puzzle do bloco.
| Pergunta | Pearl | Bittensor | Akash | Render |
|---|---|---|---|---|
| Pelo que é feito o pagamento? | Um tile de multiplicação de matrizes que cumpre a dificuldade | Resultado de uma sub-rede avaliado pelos validadores | Um aluguer de contentor aceite | Um trabalho de GPU concluído |
| Esse trabalho produz o bloco? | Sim. O tile é a lotaria de blocos da Pearl | Não. As pontuações atribuem TAO | Não. Os validadores em staking executam o CometBFT | Não. Os validadores da Solana produzem blocos |
| Ativo nativo | PRL, símbolo de mercado PEARL | TAO | AKT | RENDER |
| Qual é o aspeto de uma falha? | Não há tile vencedor, pelo que não há subsídio para esse hardware | Uma pontuação baixa, pelo que há poucas emissões ou nenhuma | Nenhuma proposta aceite ou um aluguer que não se mantém ativo | Um trabalho não liquidado para o operador |

Figura 1. A Pearl paga por um tile de multiplicação de matrizes vencedor que produz o bloco. As outras três pagam por uma pontuação, um aluguer ou um trabalho.
Um marketplace pode ter clientes pagantes enquanto a sua cadeia funciona com staking. Uma cadeia baseada em prova de trabalho útil pode produzir blocos a partir de multiplicações que nenhum cliente solicitou. Uma falha da Pearl termina essa tentativa sem subsídio, um peso baixo na Bittensor termina essa emissão, uma proposta rejeitada na Akash termina essa oferta e uma liquidação falhada na Render termina esse trabalho.
A verificação da Pearl prova um facto específico. A especificação de vírgula flutuante prolonga uma prova de multiplicação de matrizes inteiras: o minerador compromete-se com as entradas, aplica-se o ruído desses compromissos e o produto é dividido em tiles. O verificador não recalcula o produto completo. Abre um tile, verifica as provas de Merkle, deriva as sementes de ruído, recalcula esse tile e testa o bilhete face à dificuldade.
Uma aprovação significa que o tile corresponde e que o bilhete é vencedor. Não significa que um cliente recebeu tokens de um modelo. O minerador escolhe as entradas, porque uma rede aberta não pode presumir a existência de um fornecedor de tarefas honesto. O argumento de segurança é o custo da multiplicação, incluindo em entradas degeneradas, e não um registo de modelos aprovados.
Um estudo independente sobre este limite, The Usefulness Gap in Proof-of-Useful-Work, indica que a verificação aceita um produto de matrizes concluído e não testa se as matrizes vieram de um modelo. Matrizes aleatórias podem passar a verificação. O estudo indica também que o software de mineração dominante na sua amostra não continha código de inferência. Uma verificação sólida de um tile pode manter-se válida enquanto uma carga de trabalho de inferência paga continua a ser opcional.
A aprovação da Bittensor é uma pontuação. Os validadores analisam o resultado dos mineradores segundo o incentivo da sub-rede e definem pesos. Um peso elevado significa que esses validadores atribuíram valor. Não significa que todas as sub-redes vendem inferência a um cliente externo, nem que a matemática do minerador foi reexecutada como um tile de consenso. A introdução à Bittensor descreve esta separação: os mineradores produzem o recurso, os validadores avaliam os mineradores e os stakers apoiam os validadores com TAO.
A aprovação da Akash é um aluguer. A cadeia regista a proposta, a aceitação pelo cliente e os termos. A prestação é depois um facto operacional relativo a um contentor nas máquinas de um fornecedor. Um aluguer concluído não prova que as GPUs do fornecedor estão a treinar um modelo específico, a menos que a carga de trabalho do cliente seja esse trabalho.
A aprovação da Render é a liquidação de um trabalho. Um operador de nó é pago quando a rede aceita o trabalho segundo as regras aplicáveis ao trabalho e à reputação. A liquidação prova o registo do trabalho, não que os mesmos ciclos de GPU tenham constituído uma prova de bloco da Solana. A reputação pode subir ou descer de acordo com o trabalho entregue. Essa pontuação de serviço corresponde aos pesos da Bittensor e, com exceção da verificação do tile da Pearl, não é a mesma coisa.
O percurso de mineração documentado da Pearl é uma infraestrutura de GPU construída em torno de um minerador vLLM e de um nó Pearl. O nó distribui modelos de blocos. O endereço do minerador é um endereço Taproot com o prefixo prl1p na mainnet. A recompensa chega quando esse trabalho encontra um bloco: o subsídio mais as taxas, e não um pagamento por hora de disponibilidade.
Programas de terceiros publicam as suas próprias listas de dispositivos e valores de hashrate. Esses valores medem essa versão do software, não uma constante do protocolo. Um programa que solicite uma frase-semente está a apoderar-se da carteira, porque a mineração precisa apenas de um endereço de receção. Um pool pode suavizar a variância. A unidade de trabalho continua a ser a multiplicação de matrizes.
O hardware da Bittensor depende da sub-rede. Uma sub-rede de inferência pode precisar de GPUs. Uma sub-rede de armazenamento ou de previsões pode não precisar. O registo, o software do minerador e a avaliação dos validadores determinam se a máquina é paga.
O hardware da Akash é aquele que o fornecedor apresenta e que o ficheiro de implementação do cliente solicita. Ganhar o trabalho significa ganhar a proposta e manter o aluguer, não superar um objetivo de dificuldade. Um fornecedor pode ser pago por um aluguer sem qualquer possibilidade de produzir um bloco da Akash.
O hardware da Render é um nó de GPU que recebe trabalhos encaminhados. A reputação do operador e a classe do trabalho são relevantes. Uma placa que nunca ganha um tile da Pearl pode, ainda assim, concluir um trabalho da Render, porque esse trabalho não é um bilhete da Pearl.
Não. A Pearl emite PRL através do subsídio dos blocos. A oferta está limitada a 2,1 mil milhões e aproxima-se desse limite através de uma curva suave, sem uma etapa de redução para metade, com um intervalo-alvo de cerca de 194 segundos. O PRL de um minerador representa um direito sobre essa emissão, não sobre a fatura de GPU de um cliente. A mineração da Pearl acompanha essa curva juntamente com o ajuste da dificuldade.
A Bittensor paga TAO a partir da emissão que as pontuações agregadas pelo Yuma direcionam. Um minerador precisa de receber peso numa sub-rede. Um staker delega aos validadores. Nenhum destes fluxos é um pagamento de um cliente por uma hora de GPU. O token funciona como unidade de medição das pontuações.
A Akash separa a produção de blocos do pagamento do aluguer. O AKT em staking apoia os validadores e, por conseguinte, a produção de blocos. Um cliente financia o aluguer com ACT, um crédito de computação indexado ao dólar, e o depósito de garantia paga ao fornecedor em ACT. A queima de AKT é o mecanismo utilizado para criar esse crédito. Um fornecedor pode ser pago por um aluguer sem produzir blocos, e um validador pode produzir blocos sem disponibilizar uma GPU.
O RENDER é o ativo utilizado para pagar um trabalho. A queima de RENDER cria créditos de trabalho e retira esse RENDER da oferta. Os operadores de nós são pagos através de um calendário de emissões separado, e não mediante a receção dos tokens queimados. Uma conta Solana que detenha RENDER não é uma UTXO da Pearl, e uma transferência na Solana não liquida uma coinbase da Pearl. A oferta pode diminuir quando os trabalhos queimam RENDER e aumentar quando são emitidas recompensas, em vez de aumentar ou diminuir quando um tile de matrizes atinge um objetivo de dificuldade da Pearl.
Um recibo que indique "GPU" pode representar um subsídio de bloco, uma emissão ponderada por pontuações, um pagamento de aluguer ou um pagamento de emissões após um trabalho queimado. Apenas o primeiro corresponde à Pearl.
Um tile vencedor da Pearl certifica que a multiplicação cumpriu a dificuldade. Não certifica que um cliente recebeu o resultado de um modelo. Um peso da Bittensor certifica uma pontuação atribuída por um validador. Um aluguer da Akash certifica uma proposta aceite. Uma liquidação da Render certifica um trabalho concluído.
O ativo nativo da Pearl não tem um endereço de contrato noutra cadeia, e os endereços de receção da mainnet começam por prl1p. O mercado PEARL da Gate corresponde a esse ativo. O mercado PRL da Gate é a Perle, um projeto separado. Um endereço de contrato, um endereço 0x ou um endereço Solana corresponde a um ativo diferente, mesmo quando o nome é igual.
A diferença entre a Pearl, a Bittensor, a Akash e a Render está naquilo que a GPU prova. A Pearl paga PRL quando um tile de multiplicação de matrizes ganha a lotaria de blocos na sua própria cadeia, e a aprovação do verificador certifica esse tile, não uma fatura de um cliente. A Bittensor paga TAO quando os validadores avaliam o resultado de uma sub-rede. A Akash paga um aluguer aceite a partir de ACT enquanto os validadores em staking produzem blocos, e a Render queima RENDER para pagar um trabalho, enquanto as recompensas dos operadores provêm de emissões e a Solana produz os blocos.
A Pearl transforma a multiplicação de matrizes numa GPU no trabalho que pode ganhar um bloco e paga ao vencedor em PRL. A Bittensor paga TAO pelo resultado de uma sub-rede depois de os validadores definirem pontuações. A Akash regista um aluguer de contentor numa cadeia baseada em prova de participação e paga esse aluguer a partir de um depósito de garantia em ACT. A Render cobra pelos trabalhos de GPU através da queima de RENDER para obter créditos de trabalho na Solana e paga aos operadores de nós através de um calendário de emissões separado.
Não. Uma prova Pearl válida mostra que o tile aberto é recalculado corretamente e que o bilhete cumpre a dificuldade. O minerador escolhe as matrizes, e as matrizes aleatórias podem passar. Uma carga de trabalho de inferência paga pode ser a origem dessas matrizes, mas a verificação não exige essa origem.
Não. A Akash regista alugueres numa cadeia CometBFT baseada em prova de participação. A Render liquida trabalhos com RENDER na Solana, cujos validadores produzem blocos através de staking. Ambas podem vender tempo útil de GPU, mas essa venda não é o puzzle do bloco.
Não. Um fornecedor da Akash apresenta os recursos solicitados por um cliente e ganha uma proposta, enquanto um operador de nó da Render recebe um trabalho encaminhado. O percurso documentado da Pearl é composto por um nó e um minerador que executa a multiplicação do protocolo, com pagamento apenas quando é encontrado um bloco. Uma placa que pode aceitar um trabalho de um marketplace não é automaticamente um minerador Pearl.
Não. A Gate apresenta o ativo nativo da Pearl com o símbolo PEARL. O mercado PRL na Gate é a Perle, um projeto separado. O ativo nativo da Pearl é recebido num endereço prl1p da rede Pearl e não tem um endereço de contrato noutra cadeia.
* As informações não se destinam a ser e não constituem aconselhamento financeiro ou qualquer outra recomendação de qualquer tipo oferecido ou endossado pela Gate.
* Este artigo não pode ser reproduzido, transmitido ou copiado sem fazer referência à Gate. A violação é uma violação da Lei de Direitos de Autor e pode estar sujeita a ações legais.





