Pickle Chain pour les développeurs

Ce que c'est

Pickle fait tourner un séquenceur Rust sur mesure avec revm figé sur Cancun. Quand vous envoyez une transaction, elle s'exécute aussitôt - eth_sendRawTransaction bloque jusqu'à ce que le résultat existe plutôt que de rendre la promesse d'un résultat - et un reçu est disponible dans la cible d'ordonnancement du mini-bloc, environ 10 ms. Un bloc au format Ethereum enveloppant ces mini-blocs est scellé à une cible d'ordonnancement d'environ 250 ms, et c'est ce bloc que portefeuilles et explorateurs traitent comme une confirmation.

Du point de vue de l'outillage, la chaîne est ordinaire là où cela compte le plus : chain ID 78270 sur le réseau de test public que documente cette référence, ETH pour le gas, une limite de gas par bloc de 30 000 000, du JSON-RPC standard, et des en-têtes de bloc au format Cancun. forge, ethers, viem et MetaMask fonctionnent tous contre elle. Elle est aussi inhabituelle là où cela compte, et cela a sa propre page plutôt qu'un paragraphe ici.

Ce que ce n'est pas

Pickle ne se présente pas autrement que comme une chaîne à opérateur unique, et cette documentation ne publie aucun chiffre de débit. Les deux nombres de cadence ci-dessus sont des cibles d'ordonnancement - les intervalles que vise le producteur de blocs - et non des garanties de latence ni une affirmation sur le débit. Le scelleur saute un tic en retard plutôt que de rattraper.

Ce n'est pas non plus une équivalence EVM complète, et les écarts sont publiés dans leur propre page plutôt que laissés à découvrir à l'exécution. En résumé : les lectures d'état ignorent le paramètre de bloc, il n'y a pas d'archive, et error.data n'est jamais renseigné, donc votre bibliothèque ne peut pas décoder une erreur personnalisée.

La forme de la chose

Une transaction traverse trois étages, et savoir lequel vous observez fait l'essentiel de ce qui rend cette chaîne lisible :

• Exécution - immédiate, synchrone avec votre appel RPC. Un revert est connu ici.
• Préconfirmation - un mini-bloc, signé par le séquenceur, à une cible d'ordonnancement d'environ 10 ms. Votre reçu existe, et son blockNumber est encore null.
• Confirmation - un bloc EVM, à une cible d'ordonnancement d'environ 250 ms. Là, blockNumber et blockHash sont renseignés.

La finalité est un quatrième événement, séparé : elle survient une fois le lot contenant réglé sur Ethereum. Ce site n'emploie le mot pour rien d'autre.

Votre premier appel

Le réseau de test public répond à https://rpc.picklechain.xyz. Les exemples l'écrivent partout $RPC_URL, pour que la même commande tourne telle quelle contre un nœud à vous :

export RPC_URL=https://rpc.picklechain.xyz

curl -s "$RPC_URL" \
  -X POST -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# {"jsonrpc":"2.0","id":1,"result":"0x131be"}

0x131be vaut 78270. L'appel lui-même ne demande ni clé, ni compte, ni en-tête au-delà d'un type de contenu : le nœud n'authentifie rien et répond à quiconque peut l'atteindre. L'ETH de test vient du faucet, une demande par adresse toutes les 24 heures, et l'état peut être remis à zéro sans préavis.

Où aller ensuite

• Paramètres réseau - les constantes, en un tableau.
• Référence JSON-RPC - les 61 méthodes enregistrées.
• Écarts avec Ethereum - à lire avant de déboguer votre client.
• Historique et rétention - à lire avant d'écrire un indexeur.
• Actifs réels - la couche de prix : comment obtenir la liste des actifs et comment lire un prix.
• API des applications - les surfaces HTTP de première partie, qui sont une commodité et non la chaîne.
• Liste de jetons et étiquettes d'adresse - comment un jeton obtient son logo et la marque de vérification, et un contrat son étiquette : une pull request.
• L'explorateur - l'archive que le nœud n'est pas.
• Le faucet - de l'ETH de test et du PKL de test, contre une adresse collée.