Protocole PirateCash
Un aperçu technique du réseau de paiement peer-to-peer PIRATE : son grand livre UTXO, son consensus Proof-of-Stake, ses masternodes déterministes, ses LLMQ, son modèle d'émission et sa plateforme de couche 2 basée sur Tenderdash.
Révision 1.1 · juillet 2026- Temps de bloc cible
- 120 secondes
- Consensus
- PoS + LLMQ
- Offre maximale
- ≈105M PIRATE
- Licence Core
- MIT open source
Aperçu du protocole
PirateCash est un réseau de paiement décentralisé open source dont l'actif natif est PIRATE.
Le réseau tient un grand livre public UTXO sans émetteur central ni opérateur de règlement. Des nœuds indépendants valident chaque transaction et bloquent selon les mêmes règles de consensus. Les Stakers créent des blocs, tandis qu'une couche de masternode garantie fournit des services basés sur le quorum et une gouvernance décentralisée.
Validation indépendante
Chaque nœud complet vérifie les signatures de transaction, les sorties non dépensées, la structure des blocs, les preuves de mise et les limites de récompense avant d'accepter l'état.
Sécurité basée sur les enjeux
Après la phase d'amorçage, la production de blocs utilise la preuve de participation au lieu d'un calcul de hachage compétitif continu.
Réseau à deux niveaux
Les masternodes déterministes forment des quorums pour les verrous de transactions, les verrous de blocs et la gouvernance sans remplacer la validation complète des nœuds.
PirateCash Core est un fork de Dash Core et conserve son modèle UTXO dérivé de Bitcoin, sa mise en réseau peer-to-peer et son architecture de nœud de service. PirateCash modifie l'identité du réseau, les paramètres monétaires et le consensus en activant PoS au bloc 100 000.
Ouvrez le référentiel Dash Core en amontArchitecture réseau
PirateCash sépare la gestion des clés locales, la validation du consensus et les tâches de quorum de la couche de service. Cette séparation maintient la propriété du portefeuille distincte de la production de blocs et de l'exploitation du masternode.
Nœud complet
Télécharge la chaîne, gère l'ensemble UTXO et applique indépendamment toutes les règles de consensus. Un nœud complet n’a pas besoin d’être un masternode.
Jalonneur
Exécute un portefeuille synchronisé avec les sorties PIRATE éligibles et signe un bloc PoS valide lorsqu'une sortie trouve un noyau de mise.
Noeud maître
Verrouille les garanties requises, s'inscrit sur la liste déterministe et participe aux quorums de service une fois sélectionné.
Portefeuille ou intégration
Crée et signe des transactions, suit les confirmations et interroge un nœud local de confiance ou un service sécurisé séparément.
Consensus sur la preuve de participation
PoS est appliqué sur le réseau principal PirateCash depuis le bloc 100 000. Cela fait de la propriété d'un UTXO éligible, plutôt que de la puissance de hachage brute, la ressource utilisée pour proposer un bloc.
L'intervalle cible est de 120 secondes et la difficulté est ajustée en continu. La découverte de blocs reste probabiliste : détenir une participation éligible augmente les chances attendues de produire un bloc mais ne crée pas de rendement fixe ou garanti.
-
01
Sélectionnez les résultats éligibles
Le portefeuille de jalonnement prend en compte les sorties PIRATE non dépensées qui répondent aux règles de confirmation et existent depuis au moins 86 400 secondes. La garantie du masternode est protégée contre le jalonnement par défaut.
-
02
Tester le noyau de mise
Le nœud teste les sorties éligibles et les horodatages autorisés par rapport à la cible PoS actuelle. Une valeur plus éligible augmente la probabilité de sélection attendue.
-
03
Construire et signer
Lorsqu'un noyau atteint l'objectif, le portefeuille construit la transaction de mise en bloc, inclut les transactions mempool valides et signe le bloc avec la clé contrôlant la sortie sélectionnée.
-
04
Valider et propager
Les pairs vérifient que la sortie n'est pas dépensée et est mature, que le noyau et les horodatages satisfont la cible, que les signatures sont valides et que la récompense réclamée ne dépasse pas les limites du consensus.
P(bloc) ∝ participation éligible ÷ difficulté de réseau
Cette relation explique uniquement la sélection attendue ; la mise en œuvre évalue des noyaux d'enjeux discrets, et les résultats à court terme peuvent différer considérablement de la moyenne.
Le staking nécessite un nœud entièrement synchronisé et un accès sécurisé à la clé de signature. Chiffrez le portefeuille, conservez des sauvegardes hors ligne et ne le déverrouillez que pour le staking lorsque cette fonction est prise en charge. Le rendement du pool dépend des récompenses de staking effectivement obtenues et de la chance du pool à trouver des blocs. Wrapped PIRATE représente une obligation de l’opérateur envers l’utilisateur — le service reçoit des PIRATE natifs et remet en échange des jetons BEP-20. Leur prix de marché et leur négociabilité reposent sur la liquidité créée sur PancakeSwap.
Masternodes et quorums
Une liste déterministe de masternodes ancre un deuxième niveau de réseau. La garantie prouve un engagement économique à long terme ; il n'accorde pas la permission de modifier les règles de consensus. Les nœuds complets vérifient toujours les transactions, les blocs et les signatures de quorum résultants.
La garantie reste sous la clé du propriétaire mais ne doit pas être dépensée pendant que le masternode est enregistré et actif.
InstantSend
Verrouille les entrées de transaction via une signature LLMQ afin que les dépenses conflictuelles puissent être rejetées avant que la profondeur de bloc ordinaire ne s'accumule.
ChainLocks
Signe le premier bloc valide observé en hauteur, ce qui rend les réorganisations profondes beaucoup plus difficiles une fois que le réseau accepte le verrou.
Gouvernance
Les opérateurs de masternodes actifs votent sur les propositions ; les paiements approuvés peuvent être réglés via le mécanisme budgétaire de superbloc du protocole.
Corsa
Les masternodes PirateCash alimentent aussi Corsa, une messagerie décentralisée pour communiquer sans frontières avec un chiffrement end-to-end, afin de préserver la confidentialité des échanges sans dépendre d’un service central unique.
À partir de PirateCash Core v19, un masternode doit également exécuter un nœud local corsa-chat/Corsa sur le même serveur. La configuration automatique du référentiel masternode configure PirateCash Core et corsa-chat ensemble. L’exigence est décrite dans PIP-0001.
| Service | Profil du quorum | Rôle du protocole |
|---|---|---|
| ChainLocks | LLMQ_400_60 |
Signature de seuil pour les verrous de bloc |
| InstantSend | LLMQ_60_75 |
Quorum tournant pour les verrous de transaction déterministes |
| Platform | LLMQ_100_67 |
Profil de quorum réservé aux services de plateforme |
Plateforme PirateCash : couche 2 prévue
Le réseau de couche 2 ne traite pas encore l’état de l’utilisateur et ne fait pas partie du consensus actif PirateCash. La conception ci-dessous décrit l'orientation de développement prévue, et non un produit actuellement opérationnel.
PirateCash prévoit de créer sa propre plate-forme de couche 2 en tant que fork et adaptation de la pile de plate-forme open source Dash, en utilisant Tenderdash comme moteur de consensus BFT.
Tenderdash est un fork Tendermint adapté aux quorums de masternodes dynamiques et aux signatures de seuil BLS. C'est la composante consensus de la plateforme ; le stockage d'état, le protocole de données et les interfaces de développement forment des couches distinctes. Dans la version PirateCash, ces composants sont destinés à s'intégrer à la chaîne Layer 1 PoS et à la liste de masternodes déterministes PirateCash.
PirateCash Core
Les paiements natifs PIRATE, UTXO, l'émission, la preuve de participation, les masternodes et la finalité de la couche 1 restent sur la chaîne principale.
PirateCash Platform
Une chaîne d'état distincte pour une confirmation rapide, des modifications de données vérifiables et des services d'application décentralisés.
BFT finalité
Un bloc est validé après accord de plus des deux tiers de l’ensemble des validateurs actifs. Si le quorum ne peut être atteint, la finalisation doit être interrompue pour préserver la cohérence de l'état.
LLMQ et BLS
Tenderdash remplace un ensemble de validateurs statiques par des sous-ensembles de masternodes rotatifs. Une signature de seuil BLS représente la décision de quorum sous la forme d'une signature compacte.
Exécution dans le même bloc
La conception cible hérite de l'exécution du même bloc : le AppHash validé dans un en-tête de bloc représente l'état après l'exécution des transitions incluses.
Contrats de données, pas EVM
La plate-forme prévue cible les identités, les documents et les données régies par des schémas avec des transitions d'état signées. Cela n'implique pas la compatibilité EVM ou les contrats Solidity arbitraires.
Étapes de mise en œuvre
Sélectionnez une base de référence Tenderdash/Platform compatible, remplacez les identités réseau et intégrez-la avec PirateCash Core, PoS et le modèle de masternode.
consensus.MN_RRHeight = 1910840;
Au bloc 1 910 840 du réseau principal, MN_RR est activé : le protocole commence à réaffecter au credit pool la part de la récompense des masternodes destinée à Platform. Cette étape commence à alimenter le pool, mais ne lance ni n'active PirateCash Platform.
Testez DKG, la rotation du validateur, les arrêts de perte de quorum, l'état déterministe, DAPI et les mises à niveau de protocole dans des conditions contradictoires.
PirateCash Platform sera lancée ultérieurement par une activation distincte, après validation du devnet et du testnet et préparation des spécifications publiques, audits et logiciels opérateurs. Le bloc 1 910 840 n'est pas la hauteur de lancement de Platform.
Le profil LLMQ_100_67 existe déjà dans les paramètres PirateCash Core, mais cela ne signifie pas à lui seul que la couche 2 est active. Jusqu'à une activation distincte, les performances, les frais, les fonctionnalités des applications et l'économie de la plate-forme restent des objectifs de conception.
Transactions et grand livre UTXO
PIRATE est comptabilisé comme sortie de transaction non dépensée. Une transaction consomme les sorties existantes et crée de nouvelles sorties dont les conditions de dépense sont définies par des scripts et des clés cryptographiques.
Pas de solde de compte consensuel
Le solde d'un portefeuille affiché est la somme des UTXO dépensables contrôlés par ses clés. La modification d'un paiement est normalement renvoyée sous la forme d'une sortie nouvellement créée.
Frais
La différence entre le total des entrées et des sorties correspond aux frais de transaction. Les nœuds appliquent des politiques de relais et de pool de mémoire en plus des vérifications de consensus au niveau des blocs.
Propriété des clés
Le protocole reconnaît les signatures valides, pas les identités ou les demandes d'assistance. Perdre une clé privée ou une phrase de récupération signifie généralement perdre le contrôle de son PIRATE.
Confirmation et verrouillages
Une confirmation de bloc ordonne la transaction dans la chaîne PoS. InstantSend et ChainLocks ajoutent une protection signée par quorum contre les dépenses et les réorganisations conflictuelles.
Émission et distribution
PIRATE a une courbe d'émission définie par un protocole avec une offre maximale approximative de 105 millions de pièces.
Le réseau a utilisé Proof of Work jusqu’au bloc 100 000, puis Proof of Stake est devenu le mécanisme de production des blocs. La subvention de base a commencé à 50 PIRATE et est divisée par deux tous les 1 048 576 niveaux du bloc précédent. Les paiements déterministes des masternodes commencent au bloc 1 266 000, le budget DAO au bloc 1 899 666 et le financement du credit pool via MN_RR au bloc 1 910 840. Les frais de transaction s’ajoutent à la récompense autorisée sans créer eux-mêmes d’émission supplémentaire.
Lancé sans prémine
Le réseau principal PirateCash a été lancé publiquement le 3 novembre 2018 sans réserve pré-créée de PIRATE natif allouée avant le démarrage de la chaîne. Les pièces sont entrées en circulation grâce à des récompenses définies par le protocole pour les blocs produits par les participants au réseau.
- Prémine native PIRATE
- 0 PIRATE
- Lancement public
- 2018-11-03
- Récompense de bloc initiale
- 50 PIRATE
La déclaration sans prémine s'applique à la monnaie native PIRATE et au lancement de la couche 1. La représentation contractuelle BEP-20 ajoutée ultérieurement sur BNB Smart Chain possède un historique d'offre et de distribution distinct.
| Plage de blocs | Subvention de base | Phase protocolaire |
|---|---|---|
| 0–99,999 | 50 PIRATE | Phase initiale PoW |
| 100,000–1,048,575 | 50 PIRATE | PoS avec subvention de base complète |
| 1,048,576–1,265,999 | 25 PIRATE | PoS avec allocation progressive de masternodes |
| 1,266,000–1,899,665 | 25 PIRATE | Paiements déterministes des masternodes actifs |
| 1,899,666–2,097,151 | 25 PIRATE | Budget DAO ; MN_RR suit au bloc 1 910 840 |
| 2,097,152+ | 12,5 PIRATE, puis division par deux tous les 1 048 576 blocs | Émission finie à long terme |
Après le début du budget, le protocole réserve une part de subvention aux paiements de gouvernance approuvés via des superblocs.
La part du masternode commence à 0,1 % et est progressivement réaffectée vers l'objectif à long terme de 60 % défini dans Core.
Le maximum est un résultat du calendrier d'émission, et non un paramètre de jeton librement modifiable. Le consensus rejette les récompenses supérieures à la subvention autorisée.
Wrapped PIRATE sur BNB Smart Chain
Wrapped PIRATE est un jeton BEP-20 connectant le réseau natif PirateCash à un pool de jalonnement et à l'écosystème BNB Smart Chain. Un utilisateur peut déposer du PIRATE natif dans le pool et recevoir du PIRATE enveloppé conformément aux règles de service. Le pool regroupe les dépôts et utilise les pièces natives pour le jalonnement sur le réseau PirateCash, tandis que le jeton reste disponible dans le portefeuille compatible de l'utilisateur.
Le PIRATE natif et le PIRATE enveloppé sont enregistrés sur des registres distincts : le premier sur la blockchain PirateCash UTXO, le second par un contrat BEP-20 sur BNB Smart Chain. Le jeton encapsulé ne crée pas d’émission de pièces natives supplémentaire au niveau du protocole PirateCash.
Comment obtenir un PIRATE enveloppé
Obtenir wrapped PIRATE via @piratecash_bot
L’échange s’effectue via @piratecash_bot — déposez des PIRATE natifs et demandez le retrait des wrapped PIRATE vers votre adresse BNB Smart Chain (BEP-20).
Ouvrir @piratecash_bot ↗Acheter sur PancakeSwap
Le PIRATE emballé peut également être acquis directement à partir d'un pool de liquidités disponible avec un portefeuille d'auto-conservation compatible BNB Smart Chain.
Ouvrir PancakeSwap ↗0xaFCC12e4040615E7Afe9fb4330eB3D9120acAC05
BscScan ↗
Approvisionnement fixe : 64 000 000 PIRATE · 8 décimales · l'approvisionnement complet a été émis lors du déploiement du contrat
Wrapped PIRATE et le pool de staking se trouvent hors du consensus du réseau principal PirateCash. Le contrat ne crée pas automatiquement de jetons lors du dépôt et ne met pas en œuvre de pont trustless natif : la conversion entre réseaux est assurée par la passerelle du projet à partir de l'offre existante. La passerelle accessible via @piratecash_bot garantit l'échange native PIRATE ↔ wrapped PIRATE dans les deux sens. Avant un dépôt ou un échange, vérifiez l'adresse du contrat, les règles d'émission et de rachat, les frais et les conditions de conservation des monnaies natives. Le prix sur DEX, le rendement et la liquidité ne sont pas garantis par le protocole PirateCash.
Passerelle d'échange bidirectionnelle @piratecash_bot ↗Limites de sécurité et de confiance
La sécurité est multicouche : les signatures protègent la propriété, PoS ordonne des transitions d'état valides, les nœuds complets imposent le consensus et les signatures LLMQ ajoutent une protection rapide contre les conflits de transactions et les réorganisations de chaîne.
Opérations conflictuelles
Les nœuds rejettent les dépenses liées aux sorties déjà consommées, tandis que InstantSend peut verrouiller les entrées avant que la profondeur de confirmation normale ne soit atteinte.
InstantSend · UTXORéorganisations de la chaîne
ChainLocks lie l'accord de quorum à un bloc à une hauteur donnée et réduit la portée pratique de la réorganisation de l'historique accepté.
ChainLocks · LLMQMise ou récompense invalide
Chaque nœud vérifie indépendamment l'éligibilité de la mise, la cible du noyau, la signature de bloc, la validité de la transaction et la récompense maximale.
PoS · validationCompromis du portefeuille
Consensus ne peut pas restaurer les clés volées. Le cryptage, les sauvegardes des phrases de récupération, le renforcement du système et la séparation des clés des opérateurs restent la responsabilité de l'utilisateur.
signatures · backupsCe document décrit le protocole ; il ne s'agit pas d'un audit, d'une promesse d'investissement ou d'une garantie de fonctionnement ininterrompu. Le code consensus exécutable PirateCash Core fait autorité si cette présentation et une version logicielle active diffèrent.
Référence d'intégration
Les intégrations de production doivent exécuter un nœud PirateCash Core compatible, valider le réseau signalé et le bloc Genesis, attendre la confirmation ou la politique de verrouillage appropriée à leur modèle de risque et tester les mises à niveau avant le déploiement.
- Symbole natif
- PIRATE
- Décimales
- 8
- Port P2P du réseau principal
- 63636
- Préfixe de sonorisation publique
- P
- Temps de la Genèse
- 2018-11-02 23:45 UTC
- Hachage du bloc Genesis
33422d3f8e94bae7cd2544e737d64ff8ec3ee140cc3fdc4db3d14656f9a60912