Como você pode se conectar Infinite Parachains Polkadot.js

BlockX Labs Blocked Unblock Seguir Seguindo 2 de julho

Por: Jesse Abramowitz , Desenvolvedor Blockchain

Uma das grandes promessas da rede Polkadot é a interconectividade. Para a interconectividade de Polkadot, não significa apenas que cada cadeia pode se comunicar entre si, mas também que os desenvolvedores podem facilmente desenvolver em cadeias múltiplas.

Especificamente refiro-me ao Polkadot.js. Uma biblioteca JS que conecta você a um blockchain específico. Esta biblioteca na maior parte é um tamanho único para cada parachain, assim como um desenvolvedor de aplicativos eu não preciso aprender toda uma nova biblioteca para cada parachain Eu só preciso de uma biblioteca para governar todos eles.

No entanto, como com qualquer coisa, há dores de crescimento. Desde que eu acredito que o Universal Faucet é o primeiro aplicativo a se conectar a vários parachains com o Polkadot.js (o Polkascan também faz parachains, mas eles não usam o Polkadot.js … me informa se houver outros) Eu pensei que iria escrever um artigo como eu fiz e alguns dos desafios que encontrei.

Para usar a biblioteca Polkadot.js em vários parachains, você precisa do seu endpoint para a parachain desejada e seus tipos de nós customizados. Como você pode personalizar seu tempo de execução em cada parachain, é necessário informar ao Polkadot.js quais customizações foram feitas. Isso pode ser feito com um objeto JSON quando você inicializa sua instância da API.

Dito isso, vamos um por um pelos quatro parachains aos quais eu me conectei e vejo como me conectar a eles e alguns desafios que você pode encontrar.

Eu coloquei todos os tipos e exemplos personalizados em um repositório github aqui .

Robonomia

Para mim, isso deveria ser o padrão. Um simples objeto JSON eu posso ir copiando de uma página github (ou documentação), então eu posso soltá-lo no meu código e eu estou conectado.

 const api = aguardar ApiPromise.create ({ 
 fornecedor, 
 types: { 
 Ordem: { 
 modelo: "Vec <u8>", 
 objetivo: "Vec <u8>", 
 custo: "Saldo" 
 } 
 "Exigem": { 
 ordem: "ordem", 
 remetente: "AccountId" 
 } 
 Oferta: { 
 ordem: "ordem", 
 remetente: "AccountId" 
 } 
 Responsabilidade: { 
 ordem: "ordem", 
 promisee: "AccountId", 
 promisor: "AccountId", 
 resultado: “Opção <Vec <u8 >>” 
 } 
 LiabilityIndex: "u64" 
 } 

Simples e fácil Um problema que eu tive é que eu precisava do nó 10 ou superior para que isso funcionasse. Os tipos de nós podem ser encontrados nesta página do github.

Edgeware

Eu comecei conectando Edgeware através de alguns pacotes npm que eles tinham. A versão do Polkadot Keyring, aqueles pacotes usados e os que eu usei, eram os mesmos, então eu não tive nenhum problema lá.

Eles criaram desde então um objeto JSON que permite que eles se conectem. Quando eu começar a trabalhar, postarei no repositório do github para conectar-se aos parachains aqui . Mais uma vez eu recomendo usar o objeto JSON por razões que eu vou entrar mais em quando eu estava integrando Joystream.

 const {ApiPromise, WsProvider} = require (“@ polkadot / api”); 
 const {IdentityTypes} = require ('edgeware-node-types / dist / identity.js'); 
 const {VotingTypes} = exigir ('edgeware-node-types / dist / voting.js'); 
 const {GovernanceTypes} = require ('edgeware-node-types / dist / governance.js'); 
 Const getApi = async () => { 
 // Inicializa o provedor para se conectar ao nó local 
 provedor const = new WsProvider (“”); 
 // Crie a API e espere até estar pronto 
 const api = aguardar ApiPromise.create ({ 
 fornecedor, 
 types: { 
 … IdentityTypes, 
 … GovernanceTypes, 
 … VotingTypes, 
 } 
 }); 

Joysteam

É aqui que as coisas ficaram complicadas. O Joystream também usa um pacote npm para tipos personalizados. Ao usá-lo sozinho, está bem. No entanto, quando usá-lo com polkadot e edgeware não tanto. Já que cada versão dos módulos usa os mesmos pacotes, mas diferentes versões deles.

Joystream usa

 “@ Polkadot / keyring”: “0.76.1”, 
 “@ Polkadot / types”: “0.77.1”, 

Edgeware usa

 “@ Polkadot / api”: “0.79.1” 

O que significa que você recebe esse erro

 ExtError: Várias versões do @ polkadot / keyring detectadas, asseguram que existe apenas a versão 1 na sua árvore de dependências 

Para corrigir isso, levei-me a ler a documentação do fio. Há algo no fio chamado resoluções que força uma versão específica de cada pacote que você instala. Isso ajudará a resolver esse problema. Como você pode ver, esta é uma das razões pelas quais eu prefiro os objetos JSON.

Aqui está o que eu adicionei ao meu pacote JSON

“ `

 “Resoluções”: { 
 “@ Polkadot / keyring”: “0.92.1”, 
 “@ Polkadot / types”: “0.79.1” 
 } 

Centralidade

A centralidade não usa a biblioteca Polkadot.js, o que é legal, a documentação deles era bem decente. Pode ser encontrado aqui e na maior parte era bem parecido.

Na verdade, ele tem uma moeda nativa e um token de ativos nativos chamado CENNZ e CENTRAPAY, respectivamente.

O código é assim.

Não foi uma loucura para implementar, não me lembro com quais versões de fio ele trabalha, mas o meu era muito baixo e eu tive que atualizá-lo para que ele funcionasse.

Implantando

O problema surgiu porque estávamos usando o Firebase, que é ótimo, mas não instala um npm nem instala fios. Normalmente, isso seria bom, no entanto, desde que eu estou contando com resoluções de fios para resolver o meu problema de pacote isso estava em uma confusão.

Eu encontrei uma biblioteca que faria isso para npm, no entanto, quebrou com o nó 10, então novamente eu estava sem sorte.

Quase tive que criar uma pasta private_node_modules e carregar os módulos do nó problemático diretamente para o Firebase para corrigir isso.

Conclusão

Eu acho que assim como o Ethereum e o EIPS nós veremos o polkadot e os PIPs ou talvez os SIPs para o substrato… na verdade eu realmente espero que seja o SIP. Um SIP inicial que eu possa propor é ter certeza de que se os parachains quiserem se conectar à biblioteca Polkadot.js eles pelo menos fornecerão um objeto JSON para os tipos. Se eles querem ficar chiques por qualquer motivo, vá para ele, mas pelo menos tenha o objeto JSON. Além disso, algum tipo de repo global para esses objetos seria muito bom (eu criei o início de um aqui ).

Texto original em inglês.