So verwendest du getLeaderSchedule

​

Häufige Anwendungsfälle

• Netzwerküberwachung: Beobachte, wie die Leader-slot in einer Epoche auf die Validatoren verteilt sind.
• Transaktionsrouting (fortgeschritten): Einige fortgeschrittene Anwendungen versuchen möglicherweise, Transaktionen an den aktuellen oder nächsten Leader weiterzuleiten. In der Regel übernehmen dies jedoch das Netzwerk und die RPC-nodes.
• Analyse der Validatorleistung: Vergleiche den Leader-Zeitplan mit der tatsächlichen Blockproduktion, um Verfügbarkeit und Leistung der Validatoren zu bewerten.
• Epochenverlauf nachvollziehen: Prüfe, welche Validatoren während einer Epoche für die Blockproduktion verantwortlich sind.

​

Parameter für den request

1. slot (u64, optional): Eine slot-Nummer. Wenn du sie angibst, wird der Leader-Zeitplan für die Epoche abgerufen, die diesen slot enthält. Wenn du null angibst oder den Parameter weglässt, wird der Leader-Zeitplan für die aktuelle Epoche abgerufen.
2. config (object, optional): Ein Konfigurationsobjekt, das Folgendes enthalten kann:
   • commitment (string, optional): Gibt das Level für commitment an. Wenn du es nicht angibst, wird das vom node vorgegebene commitment verwendet.
   • identity (string, optional): Der Base58-codierte öffentliche Schlüssel eines Validators. Wenn du ihn angibst, enthält der zurückgegebene Zeitplan nur slot, die diesem Validator zugewiesen sind.

​

Struktur der response

• null: Wenn die zum angeforderten slot gehörende Epoche nicht gefunden wurde oder ihr Leader-Zeitplan nicht verfügbar ist. Wenn du keinen slot angibst, gilt dies für die aktuelle Epoche. Das kann beispielsweise bei einer zukünftigen, noch nicht berechneten Epoche der Fall sein.
• Ein Objekt: Wenn ein Zeitplan gefunden wurde. Dieses Objekt ist eine Zuordnung, bei der:
  • jeder Schlüssel der Base58-codierte öffentliche Schlüssel (die Identität) eines Validators ist.
  • der zugehörige Wert ein Array aus Zahlen ist. Jede Zahl ist ein slot-Index relativ zum Beginn der Epoche, für den dieser Validator der Leader ist.

​

Beispiele

​

1. Leader-Zeitplan für die aktuelle Epoche abrufen

# Replace <api-key> with your Helius API key
curl https://mainnet.helius-rpc.com/?api-key=<api-key> -X POST -H "Content-Type: application/json" -d \
  '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLeaderSchedule"
  }'

// Replace <api-key> with your Helius API key
const { Connection } = require('@solana/web3.js');

async function fetchCurrentLeaderSchedule() {
  const connection = new Connection('https://mainnet.helius-rpc.com/?api-key=<api-key>');
  try {
    const leaderSchedule = await connection.getLeaderSchedule(); // Fetches for current epoch by default
    if (leaderSchedule) {
      console.log('Leader Schedule for Current Epoch:');
      for (const [validatorIdentity, slots] of Object.entries(leaderSchedule)) {
        console.log(`  Validator: ${validatorIdentity}`);
        console.log(`    Slots (relative to epoch start): ${slots.join(', ')}`);
      }
    } else {
      console.log('Leader schedule for the current epoch not found or not yet available.');
    }
    // console.log(JSON.stringify(leaderSchedule, null, 2));
  } catch (error) {
    console.error('Error fetching leader schedule:', error);
  }
}

fetchCurrentLeaderSchedule();

​

2. Leader-Zeitplan für einen bestimmten Validator in einer bestimmten Epoche abrufen (über einen slot)

# Replace <api-key> with your Helius API key
# Replace VALIDATOR_PUBKEY with an actual validator identity public key
curl https://mainnet.helius-rpc.com/?api-key=<api-key> -X POST -H "Content-Type: application/json" -d \
  '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLeaderSchedule",
    "params": [
      200000,
      { "identity": "VALIDATOR_PUBKEY" }
    ]
  }'

// Replace <api-key> with your Helius API key
// Replace VALIDATOR_PUBKEY with an actual validator identity public key
const { Connection, PublicKey } = require('@solana/web3.js');

async function fetchValidatorEpochSchedule() {
  const connection = new Connection('https://mainnet.helius-rpc.com/?api-key=<api-key>');
  const targetSlot = 200000;
  const validatorIdentity = 'VALIDATOR_PUBKEY'; // e.g., 'Vote111111111111111111111111111111111111111'

  try {
    const leaderSchedule = await connection.getLeaderSchedule(targetSlot, { identity: validatorIdentity });
    if (leaderSchedule && leaderSchedule[validatorIdentity]) {
      console.log(`Leader Schedule for Validator ${validatorIdentity} in epoch of slot ${targetSlot}:`);
      console.log(`  Slots (relative to epoch start): ${leaderSchedule[validatorIdentity].join(', ')}`);
    } else {
      console.log(`No leader slots found for validator ${validatorIdentity} in epoch of slot ${targetSlot}, or schedule not available.`);
    }
    // console.log(JSON.stringify(leaderSchedule, null, 2));
  } catch (error) {
    console.error('Error fetching validator leader schedule:', error);
  }
}

fetchValidatorEpochSchedule();

​

Tipps für Entwickler

• Epochengrenzen: Der Leader-Zeitplan gilt unverändert für eine gesamte Epoche. Mit getEpochInfo kannst du den ersten und letzten slot einer Epoche ermitteln.
• Zukünftige Epochen: Wenn du den Zeitplan für eine weit in der Zukunft liegende Epoche anforderst, kann null zurückgegeben werden, falls das Netzwerk ihn noch nicht berechnet hat.
• Relative slot-Indizes: Beachte, dass die slot-Nummern in der response relativ zum ersten slot der angeforderten Epoche sind. Es handelt sich nicht um absolute slot-Nummern auf der Blockchain.
• Große response: Die response für den vollständigen Zeitplan einer Epoche kann ohne Identitätsfilter groß sein, da sie alle Validatoren und die ihnen zugewiesenen slot auflistet.

​

Verwandte Methoden