Konfiguration

Sie verwenden Kora v2.2.0-beta? Siehe Beta-Konfiguration für neue Optionen: Jito-Bundles, Lighthouse-Schutz, reCAPTCHA und Nutzungslimits.

Ihr Kora-Node wird Transaktionen für Ihre Nutzer signieren, daher ist es wichtig, ihn so zu konfigurieren, dass er nur Transaktionen signiert, die Ihre geschäftlichen Anforderungen erfüllen. Kora bietet Ihnen viel Flexibilität bei der Konfiguration Ihres Nodes, aber es ist wichtig, die Auswirkungen Ihrer Konfiguration zu verstehen. kora.toml ist die Steuerzentrale für Ihre Kora-Konfiguration. Dieses Dokument bietet eine umfassende Referenz zur Konfiguration Ihres Kora-Paymaster-Nodes über die kora.toml-Konfigurationsdatei.

Überblick

Die kora.toml-Datei steuert alle Aspekte des Verhaltens Ihres Kora-Nodes, einschließlich:

• Ratenbegrenzung und Authentifizierung
• RPC-Methodenverfügbarkeit
• Transaktionsvalidierungsregeln
• Gebührenpreismodelle
• Sicherheitsrichtlinien
• RPC-Methodenverfügbarkeit
• Gebührenpreismodelle
• Konfiguration der Zahlungsadresse
• Leistungsüberwachung

Ihre Konfigurationsdatei sollte in Ihrem Deployment-Verzeichnis abgelegt oder über das --config-Flag beim Starten des Servers angegeben werden.

Konfigurationsabschnitte

Die kora.toml-Datei ist in Abschnitte unterteilt, die jeweils eigene Optionen haben. Dieser Leitfaden führt durch jeden Abschnitt und erklärt die verfügbaren Optionen:

• Kora Core Policies - Zentrale Servereinstellungen
• Kora Authentication - Authentifizierungseinstellungen
• Kora Caching - Redis-Caching für RPC-Aufrufe
• Kora Usage Limits - Transaktionslimits pro Wallet
• Kora Enabled Methods - Zu aktivierende Kora-RPC-Methoden
• Validation Policies - Transaktionsvalidierung und Sicherheit
• Token-2022 Extension Blocking - Blockierung riskanter Token-2022-Erweiterungen
• Fee Payer Policy - Einschränkungen für Gebührenzahler-Wallet
• Price Configuration - Preismodelle für Transaktionsgebühren
• Performance Monitoring - Metriken- Erfassung und Überwachung
• Complete Example - Vollständige produktionsreife Konfiguration

Beispiel-kora.toml-Dateiabschnitte:

[kora]
# Core server settings

[kora.auth]
# Authentication settings

[kora.cache]
# Redis caching configuration

[kora.usage_limit]
# Per-wallet transaction limiting

[kora.enabled_methods]
# Kora RPC methods to enable

[validation]
# Transaction validation rules

[validation.token2022]
# Token-2022 extension blocking

[validation.fee_payer_policy]
# Restrictions on fee payer wallet

[validation.price]
# Transaction fee pricing models

[metrics]
# Performance monitoring

Kora-Kernrichtlinien

Der Abschnitt [kora] konfiguriert das zentrale Serververhalten:

[kora]
rate_limit = 100
payment_address = "YourPaymentAddressPubkey11111111111111111111"  # Optional

Kora-Authentifizierung

Der Abschnitt [kora.auth] konfiguriert die Authentifizierung für den Kora-Server:

[kora.auth]
api_key = "kora_live_sk_1234567890abcdef"
hmac_secret = "kora_hmac_your-strong-hmac-secret-key-here"
max_timestamp_age = 300

Hinweis: api_key und hmac_secret legen eine globale Authentifizierungsrichtlinie für alle Clients fest. Für eine detaillierte Einrichtung der Authentifizierung siehe Authentifizierungsleitfaden.

Kora-Caching (optional)

Der Abschnitt [kora.cache] konfiguriert Redis-basiertes Caching für Solana-RPC-Aufrufe. Dies kann die Performance erheblich verbessern, indem redundante Abrufe von Kontodaten reduziert werden:

[kora.cache]
enabled = true                      # Enable/disable caching
url = "redis://localhost:6379"      # Redis connection URL
default_ttl = 300                   # Default TTL in seconds (5 minutes)
account_ttl = 60                    # Account data TTL in seconds (1 minute)

Hinweis: Wenn Caching aktiviert ist, muss eine Redis-Instanz unter der angegebenen URL verfügbar sein. Der Cache greift elegant auf direkte RPC-Aufrufe zurück, falls Redis nicht verfügbar ist.

Kora-Nutzungslimits (optional)

Der Abschnitt [kora.usage_limit] konfiguriert die Transaktionsbegrenzung pro Wallet, um Missbrauch zu verhindern und eine faire Nutzung für alle Benutzer sicherzustellen. Dies könnte auch verwendet werden, um Prämienprogramme zu erstellen, die die Transaktionsgebühren der Benutzer bis zu einem bestimmten Limit subventionieren.

Wichtig: Derzeit ist die einzige Form der Nutzungsbegrenzung, die von Kora unterstützt wird, ein permanentes Limit. Sobald eine Wallet ihr Transaktionslimit erreicht hat, kann es nicht zurückgesetzt werden und der Benutzer wird keine weiteren Transaktionen mehr mit derselben Wallet einreichen können. Dieses Limit bleibt bestehen, bis es manuell aus Redis gelöscht wird oder die Redis-Daten zurückgesetzt werden.

Hinweis: Diese Funktion erfordert Redis, wenn sie über mehrere Kora-Instanzen hinweg aktiviert ist:

[kora.usage_limit]
enabled = true                      # Enable/disable usage limiting
cache_url = "redis://localhost:6379" # Redis URL for shared state (required when enabled)
max_transactions = 100              # Max transactions per wallet (0 = unlimited)
fallback_if_unavailable = true      # Continue if Redis is unavailable

Hinweis: Nutzungslimits werden pro Wallet-Adresse mit automatischem TTL-basiertem Ablauf verfolgt. Wenn fallback_if_unavailable auf true gesetzt ist, erlaubt das System die Fortsetzung von Transaktionen, falls Redis vorübergehend nicht verfügbar ist, um Dienstunterbrechungen zu vermeiden. Wenn max_transactions auf 0 gesetzt wird, werden unbegrenzt Transaktionen zugelassen.

Kora-aktivierte Methoden (optional)

Der Abschnitt [kora.enabled_methods] steuert, welche RPC-Methoden aktiviert sind. Dieser Abschnitt ist optional und standardmäßig sind alle Methoden aktiviert. Jede Methode kann aktiviert oder deaktiviert werden, indem der Wert auf true oder false gesetzt wird:

[kora.enabled_methods]
liveness = true
estimate_transaction_fee = true
get_supported_tokens = true
sign_transaction = false
sign_and_send_transaction = false
transfer_transaction = false
get_blockhash = true
get_config = true
get_payer_signer = true

Hinweis: Falls dieser Abschnitt in Ihrer kora.toml-Datei enthalten ist, müssen alle Methoden explizit auf true oder false gesetzt werden.

Validierungsrichtlinien

Der Abschnitt [validation] definiert Solana-bezogene Sicherheitsregeln und Transaktionslimits:

[validation]
max_allowed_lamports = 1000000  # 0.001 SOL
max_signatures = 10
price_source = "Jupiter"
allow_durable_transactions = false  # Block durable nonce transactions
allowed_programs = [
    "11111111111111111111111111111111",              # System Program (required for SOL transfers)
    "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",   # SPL Token Program
    "TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb",   # Token-2022 Program
    "ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL",  # Associated Token Program
    "AddressLookupTab1e1111111111111111111111111",   # Address Lookup Table Program
    "ComputeBudget11111111111111111111111111111111", # Compute Budget Program
]
allowed_tokens = [
    "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",  # USDC (mainnet)
    # additional tokens here
]
allowed_spl_paid_tokens = [
    "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",  # USDC (mainnet)
    # additional tokens here
]
disallowed_accounts = [
    # "BadActorPubkey11111111111111111111111111111",
]

Hinweis: Leere Arrays sind zulässig, aber Sie müssen mindestens ein freigegebenes allowed_programs, allowed_tokens, allowed_spl_paid_tokens angeben, damit der Kora-Knoten Transaktionen verarbeiten kann. Sie müssen das System Program oder Token Program angeben, damit der Kora-Knoten Überweisungen verarbeiten kann. Um gängige Anweisungstypen (z. B. Compute Budget, Address Lookup Table) zu aktivieren, müssen Sie das Compute Budget Program oder Address Lookup Table Program usw. angeben.

Dauerhafte Transaktionssicherheit

SICHERHEITSWARNUNG: Dauerhafte Nonce-Transaktionen ermöglichen es, signierte Transaktionen unbegrenzt aufzubewahren und später einzureichen. Dies könnte als wirtschaftlicher Angriffsvektor genutzt werden, bei dem jemand eine signierte Transaktion erhalten und mit der Einreichung warten könnte, bis die Marktbedingungen für ihn günstig sind (z. B. wenn der Wert von SOL gesunken ist oder der Wert des Zahlungstokens gestiegen ist).

Standardmäßig ist allow_durable_transactions auf false gesetzt, um alle dauerhaften Nonce-Transaktionen zu blockieren. Aktivieren Sie dies nur, wenn Ihre Anwendung ausdrücklich dauerhafte Transaktionen erfordert und Sie die Risiken verstehen.

Wenn Sie dauerhafte Transaktionen aktivieren müssen, beachten Sie Folgendes:

• Verwendung von Authentifizierung zur Einschränkung des API-Zugriffs
• Implementierung zusätzlicher Off-Chain-Validierung
• Überwachung auf ungewöhnliche Transaktionsmuster
• Überwachung und Begrenzung von Signer-Kontenguthaben
• Regelmäßige Rotation von Signer-Schlüsseln

Erfahren Sie mehr über dauerhafte Nonce-Transaktionen in den Solana Docs.

Blockierung von Token-2022-Erweiterungen

Der Abschnitt [validation.token2022] ermöglicht es Ihnen, bestimmte Token-2022-Erweiterungen für erhöhte Sicherheit zu blockieren. Alle Erweiterungen sind standardmäßig aktiviert. Sie können bestimmte Erweiterungen blockieren, indem Sie sie zu den Arrays blocked_mint_extensions oder blocked_account_extensions hinzufügen:

[validation.token2022]
blocked_mint_extensions = [
    "transfer_hook",           # Block tokens with transfer hooks
    "pausable",                # Block pausable tokens
    "permanent_delegate",      # Block tokens with permanent delegates
]
blocked_account_extensions = [
    "cpi_guard",              # Block accounts with CPI guard
    "memo_transfer",          # Block accounts requiring memos
]

Verfügbare Mint-Erweiterungen

Verfügbare Konto-Erweiterungen

transfer_hook

Sicherheitsüberlegungen

PermanentDelegate-Erweiterung - Token mit dieser Erweiterung ermöglichen es dem Delegierten, Token jederzeit ohne Genehmigung des Inhabers zu übertragen/zu brennen. Dies birgt erhebliche Risiken für den Kora-Node-Betreiber, da Zahlungsmittel nach der Zahlung beschlagnahmt werden können.

• Erwägen Sie, "permanent_delegate" zu blocked_mint_extensions in [validation.token2022] hinzuzufügen, sofern dies nicht ausdrücklich für Ihren Anwendungsfall erforderlich ist.
• Vermeiden Sie die Verwendung von Zahlungs-Token mit der permanent_delegate-Erweiterung.

Fee-Zahler-Richtlinie

Der Abschnitt [validation.fee_payer_policy] bietet eine detaillierte Kontrolle darüber, welche Aktionen das Fee-Zahler-Wallet Ihres Kora-Knotens ausführen kann. Die Richtlinie ist nach Programmtyp (System, SPL Token, Token-2022) organisiert und deckt alle verschiedenen Anweisungstypen ab. Dies verhindert unerwartetes Verhalten bei Transaktionen von Benutzern, die Ihren Kora-Knoten als Signer verwenden.

Beispielsweise wird der Kora-Knoten, wenn spl_token.allow_transfer auf false gesetzt ist, keine Transaktionen signieren, die eine SPL-Token-Übertragung enthalten, bei der der Fee-Zahler des Kora-Knotens die Übertragungsberechtigung ist.

[validation.fee_payer_policy.system]
allow_transfer = false           # System Transfer/TransferWithSeed
allow_assign = false             # System Assign/AssignWithSeed
allow_create_account = false     # System CreateAccount/CreateAccountWithSeed
allow_allocate = false           # System Allocate/AllocateWithSeed

[validation.fee_payer_policy.system.nonce]
allow_initialize = false         # InitializeNonceAccount
allow_advance = false            # AdvanceNonceAccount
allow_authorize = false          # AuthorizeNonceAccount
allow_withdraw = false           # WithdrawNonceAccount

[validation.fee_payer_policy.spl_token]
allow_transfer = false           # Transfer/TransferChecked
allow_burn = false               # Burn/BurnChecked
allow_close_account = false      # CloseAccount
allow_approve = false            # Approve/ApproveChecked
allow_revoke = false             # Revoke
allow_set_authority = false      # SetAuthority
allow_mint_to = false            # MintTo/MintToChecked
allow_initialize_mint = false    # InitializeMint/InitializeMint2
allow_initialize_account = false # InitializeAccount/InitializeAccount3
allow_initialize_multisig = false # InitializeMultisig/InitializeMultisig2
allow_freeze_account = false     # FreezeAccount
allow_thaw_account = false       # ThawAccount

[validation.fee_payer_policy.token_2022]
allow_transfer = false           # Transfer/TransferChecked
allow_burn = false               # Burn/BurnChecked
allow_close_account = false      # CloseAccount
allow_approve = false            # Approve/ApproveChecked
allow_revoke = false             # Revoke
allow_set_authority = false      # SetAuthority
allow_mint_to = false            # MintTo/MintToChecked
allow_initialize_mint = false    # InitializeMint/InitializeMint2
allow_initialize_account = false # InitializeAccount/InitializeAccount3
allow_initialize_multisig = false # InitializeMultisig/InitializeMultisig2
allow_freeze_account = false     # FreezeAccount
allow_thaw_account = false       # ThawAccount

System Program Anweisungen

SPL Token Program Anweisungen

Token-2022 unterstützt denselben Befehlssatz wie SPL Token mit identischen Konfigurationsoptionen (unter dem Abschnitt [validation.fee_payer_policy.token_2022]).

Sicherheitsüberlegungen

SICHERHEITSWARNUNG: Aus Sicherheitsgründen wird empfohlen, alle diese Einstellungen auf false (Standard) zu setzen und nur bei Bedarf zu aktivieren. Dies verhindert unerwünschtes Verhalten wie das Entleeren Ihres Fee-Zahler-Kontos durch Benutzer oder das Verbrennen von Token von Ihrem Fee-Zahler-Konto. Dies verhindert:

• Konten-Entleerung: Benutzer übertragen SOL oder Token von Ihrem Fee-Zahler-Konto
• Autoritätsübernahme: Benutzer ändern Berechtigungen für Konten, die Ihrem Fee-Zahler gehören
• Unbefugtes Prägen: Benutzer prägen Token, wenn Ihr Fee-Zahler Prägeberechtigung hat
• Konten-Manipulation: Benutzer frieren ein, schließen oder ändern Konten, die von Ihrem Fee-Zahler kontrolliert werden

Best Practice: Beginnen Sie mit allen deaktivierten Berechtigungen und aktivieren Sie nur die minimal erforderlichen für Ihren spezifischen Anwendungsfall.

Preiskonfiguration (optional)

Der Abschnitt [validation.price] definiert, wie Transaktionsgebühren berechnet werden. Drei Preismodelle stehen zur Verfügung:

• Margen-Preisgestaltung (Standard) - Fügen Sie einen prozentualen Aufschlag auf die tatsächlichen Netzwerkgebühren hinzu (Standardmarge ist 0,0)
• Festpreis-Preisgestaltung - Berechnen Sie einen festen Betrag in einem bestimmten Token unabhängig von Netzwerkgebühren
• Kostenlose Preisgestaltung - Sponsern Sie alle Transaktionsgebühren (keine Gebühren für Benutzer)

Margin-Preisgestaltung

Fügen Sie einen prozentualen Aufschlag zu den tatsächlichen Netzwerkgebühren hinzu:

[validation.price]
type = "margin"
margin = 0.1  # 10% margin (0.1 = 10%, 1.0 = 100%)

Festpreisgestaltung

SICHERHEITSWARNUNG: Die Festpreisgestaltung berücksichtigt NICHT die Ausgaben des Gebührenzahlers im berechneten Betrag. Dies kann es Benutzern ermöglichen, Ihr Gebührenzahler-Konten zu leeren, wenn es nicht ordnungsgemäß konfiguriert ist.

Berechnen Sie einen festen Betrag in einem bestimmten Token, unabhängig von den Netzwerkgebühren:

[validation.price]
type = "fixed"
amount = 1000000  # Amount in token's base units
token = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"  # USDC mint

Kostenlose Transaktionen

Übernehmen Sie alle Transaktionsgebühren (keine Gebühren für Benutzer):

[validation.price]
type = "free"

Sicherheitsmaßnahmen bei Verwendung von Festpreis-/Kostenlos-Preisgestaltung

1. Alle Überweisungs- und Geldtransaktionen deaktivieren - Verhindern Sie, dass der Gebührenzahler als Quelle bei Überweisungen verwendet wird:

   [validation.fee_payer_policy.system]
   allow_transfer = false              # Block SOL transfers
   allow_create_account = false        # Block account creation with lamports
   allow_allocate = false              # Block space allocation
   
   [validation.fee_payer_policy.system.nonce]
   allow_withdraw = false              # Block nonce account withdrawals
   
   [validation.fee_payer_policy.spl_token] # and for [validation.fee_payer_policy.token_2022]
   allow_transfer = false              # Block SPL transfers
   allow_burn = false                  # Block SPL token burning
   allow_close_account = false         # Block SPL token account closures (returns rent)
   allow_mint_to = false               # Block unauthorized SPL token minting
   allow_initialize_account = false    # Block account initialization

2. Authentifizierung aktivieren - Verwenden Sie Authentifizierung, um Missbrauch zu verhindern:

   [kora.auth]
   api_key = "your-secure-api-key"
   # or
   hmac_secret = "your-minimum-32-character-hmac-secret"

3. Konservative Limits festlegen - Minimieren Sie das Risiko:

   [validation]
   max_allowed_lamports = 1000000  # 0.001 SOL maximum

WARNUNG: Besonders gefährliche Operationen bei Verwendung von Festpreis-/Kostenlos-Preisgestaltung:

• allow_mint_to: Könnte unbegrenzte Token-Erstellung ermöglichen, wenn der Gebührenzahler über Mint-Berechtigung verfügt
• allow_set_authority: Könnte die Kontrolle über kritische Konten an Angreifer übertragen
• allow_transfer: Ermöglicht direktes Abschöpfen der Token-Guthaben des Gebührenzahlers
• allow_close_account: Gibt Miete an Konten zurück, die von Angreifern kontrolliert werden

Leistungsüberwachung (optional)

Der Abschnitt [metrics] konfiguriert die Erfassung und Überwachung von Metriken. Dieser Abschnitt ist optional und standardmäßig sind Metriken deaktiviert.

[metrics]
enabled = true
endpoint = "/metrics"
port = 8080
scrape_interval = 60

[metrics.fee_payer_balance]
enabled = true
expiry_seconds = 30

Gebührenzahler-Saldo-Verfolgung

Der Abschnitt [metrics.fee_payer_balance] konfiguriert die automatische Überwachung des SOL-Guthabens Ihres Gebührenzahlers:

Wenn aktiviert, verfolgt Kora automatisch den SOL-Saldo Ihres Gebührenzahlers und stellt ihn über die Prometheus-Metrik fee_payer_balance_lamports bereit. Dies hilft bei der Kapazitätsplanung und Warnungen bei niedrigem Guthaben.

http://localhost:{port}/{metrics-endpoint}

→ Kora Monitoring-Referenzhandbuch

Vollständiges Beispiel

Hier ist eine produktionsreife Konfiguration mit bewährten Sicherheitspraktiken:

# Kora Paymaster Configuration
# Last Updated: 2025-08-22

[kora]
# Rate limiting: 100 requests per second globally
rate_limit = 100

# Optional payment address (defaults to signer address(es) if not specified)
# payment_address = "YourPaymentAddressPubkey11111111111111111111"

[kora.auth]
# Authentication (choose based on security needs)
# api_key = "kora_live_sk_generate_secure_key_here"
hmac_secret = "kora_hmac_minimum_32_character_secret_here"
max_timestamp_age = 300

# Caching configuration (optional but recommended for production)
[kora.cache]
enabled = true
url = "redis://localhost:6379"
default_ttl = 300  # 5 minutes
account_ttl = 60   # 1 minute

# Usage limiting (optional, prevents abuse)
[kora.usage_limit]
enabled = true
cache_url = "redis://localhost:6379"  # Can share same Redis instance as cache
max_transactions = 100                # Per-wallet limit
fallback_if_unavailable = true        # Don't block if Redis is down

# Disable unnecessary RPC methods for security
[kora.enabled_methods]
liveness = true
estimate_transaction_fee = true
get_supported_tokens = true
sign_transaction = false
sign_and_send_transaction = false
transfer_transaction = false
get_blockhash = true
get_config = true
get_payer_signer = true

[validation]
# Use production oracle
price_source = "Jupiter"

# Conservative transaction limits
max_allowed_lamports = 1000000  # 0.001 SOL max
max_signatures = 10

# Block durable nonce transactions (security default)
allow_durable_transactions = false

# Minimal program allowlist (expand as needed)
allowed_programs = [
    "11111111111111111111111111111111",              # System Program
    "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",   # SPL Token
    "ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL",  # Associated Token
    "AddressLookupTab1e1111111111111111111111111",   # Address Lookup Table
    "ComputeBudget11111111111111111111111111111111", # Compute Budget
    "MyProgram111111111111111111111111111111111",
    # Add your specific program IDs here
]

# Production token allowlist
allowed_tokens = [
    "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",  # USDC
    "So11111111111111111111111111111111111111112",   # Wrapped SOL
    "MyToken1111111111111111111111111111111111111111",
    # Add tokens your application uses
]

# Payment tokens (only liquid, trusted tokens)
allowed_spl_paid_tokens = [
    "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",  # USDC only
]

# Known bad actors or compromised addresses
disallowed_accounts = [
    "BadActor1111111111111111111111111111111111111111",
]

# Restrictive fee payer policy (recommended for production)
[validation.fee_payer_policy.system]
allow_transfer = false           # Block SOL transfers from fee payer
allow_assign = false             # Block account ownership changes
allow_create_account = false     # Block creating accounts with fee payer funds
allow_allocate = false           # Block allocating space for fee payer accounts

[validation.fee_payer_policy.system.nonce]
allow_initialize = false         # Block nonce account initialization
allow_advance = false            # Block nonce advancement
allow_authorize = false          # Block nonce authority changes
allow_withdraw = false           # Block nonce withdrawals

[validation.fee_payer_policy.spl_token]
allow_transfer = false           # Critical: Block SPL transfers
allow_burn = false               # Block token burning
allow_close_account = false      # Block account closures
allow_approve = false            # Block token approvals
allow_revoke = false             # Block delegate revocations
allow_set_authority = false      # Block authority changes
allow_mint_to = false            # Block minting operations
allow_initialize_mint = false    # Block mint initialization
allow_initialize_account = false # Block account initialization
allow_initialize_multisig = false # Block multisig initialization
allow_freeze_account = false     # Block account freezing
allow_thaw_account = false       # Block account thawing

[validation.fee_payer_policy.token_2022]
allow_transfer = false           # Critical: Block Token2022 transfers
allow_burn = false               # Block token burning
allow_close_account = false      # Block account closures
allow_approve = false            # Block token approvals
allow_revoke = false             # Block delegate revocations
allow_set_authority = false      # Block authority changes
allow_mint_to = false            # Block minting operations
allow_initialize_mint = false    # Block mint initialization
allow_initialize_account = false # Block account initialization
allow_initialize_multisig = false # Block multisig initialization
allow_freeze_account = false     # Block account freezing
allow_thaw_account = false       # Block account thawing

# Token-2022 extension blocking
[validation.token2022]
# Block potentially risky mint extensions
blocked_mint_extensions = [
    "transfer_hook",       # Custom transfer logic
    "pausable",            # Can freeze transfers
    "permanent_delegate",  # Permanent control
]
# Block complex account extensions
blocked_account_extensions = [
    "cpi_guard",      # Restricts composability
    "memo_transfer",  # Requires additional data
]

# Sustainable pricing with 15% margin
[validation.price]
type = "margin"
margin = 0.15  # 15% margin on network fees

# Metrics collection
[metrics]
enabled = true
endpoint = "/metrics"
port = 8080
scrape_interval = 60

# Fee payer balance monitoring
[metrics.fee_payer_balance]
enabled = true
expiry_seconds = 30

Konfigurationsvalidierung

Kora validiert Ihre Konfiguration beim Start. Wenn Sie Ihre Konfiguration validieren möchten, ohne den Server zu starten, können Sie den Befehl zur Konfigurationsvalidierung verwenden:

kora --config kora.toml config validate # or validate-with-rpc

Sie können auch den Befehl validate-with-rpc ausführen, um Ihre Konfiguration mit dem RPC-Server zu validieren (diese Validierungsprüfung ist etwas langsamer, führt aber gründlichere Kontoprüfungen durch)

Server starten

Sobald Sie Ihre kora.toml-Datei konfiguriert haben, können Sie den Kora-Server starten:

kora --config path/to/kora.toml rpc start --no-load-signer # --other-rpc-flags-here

Das Flag --no-load-signer initialisiert den Server, ohne Signer zu laden. Dies ist nützlich zum Testen Ihrer Konfiguration. Um Signer zu laden, müssen Sie die signers.toml-Datei konfigurieren. Eine Minimalkonfiguration mit einem einzelnen Signer würde folgendermaßen aussehen:

[signer_pool]
# Selection strategy: round_robin, random, weighted
strategy = "round_robin"

# Primary memory signer
[[signers]]
name = "my-signer"
type = "memory"
private_key_env = "MY_SIGNER_PRIVATE_KEY"

Dadurch wird ein einzelner Signer aus der Umgebungsvariablen MY_SIGNER_PRIVATE_KEY geladen. Anschließend können Sie Ihren Server starten mit:

kora --config path/to/kora.toml rpc start --signers-config path/to/signers.toml

Weitere Informationen und erweiterte Signer-Konfiguration finden Sie im Signers-Leitfaden.

Best Practices

1. Restriktiv beginnen: Starten Sie mit engen Limits und erweitern Sie diese schrittweise
2. Nutzung überwachen: Verfolgen Sie, welche Programme und Token tatsächlich verwendet werden
3. Regelmäßige Updates: Überprüfen und aktualisieren Sie Blocklisten und Limits
4. Änderungen testen: Validieren Sie Konfigurationsänderungen zuerst in der Staging-Umgebung
5. Versionierung: Führen Sie ein Änderungsprotokoll Ihrer Konfigurationsänderungen

Benötigen Sie Hilfe?

• Siehe Authentifizierungs-Leitfaden für die Einrichtung der Authentifizierung
• Siehe Signers-Leitfaden für die Signer-Konfiguration
• Siehe Operator-Leitfaden für weitere Informationen zum Betrieb eines Kora-Knotens
• Besuchen Sie Solana Stack Exchange mit dem kora-Tag
• Melden Sie Probleme auf GitHub