Midnight verlagert Mainnet RPC und Indexer zu Blockfrost

Produktiv eingesetzte Anwendungen benötigen nun Blockfrost Endpunkte und Projekt Authentifizierung. Einige Wallets müssen möglicherweise auch den Synchronisationszustand neu aufbauen, der gegen den früheren Indexer von Midnight gespeichert wurde.

By SongMarketCap

Cardano News - Midnight verlagert Mainnet RPC und Indexer zu Blockfrost

Midnight hat seine eigenen öffentlichen Mainnet RPC und Indexer Endpunkte am 30. September um 22:00 UTC außer Betrieb genommen. Blockfrost stellt nun den primären öffentlichen Zugang zu diesen Diensten bereit, was die Art und Weise ändert, wie Anwendungen und Wallets sich mit dem Produktionsnetzwerk verbinden.

Midnight Mainnet Endpunkte sind außer Betrieb

Die Änderung betrifft rpc.mainnet.midnight.network und indexer.mainnet.midnight.network. Laut der Dokumentation von Midnight löst der Indexer Hostname seit dem 1. Oktober nicht mehr auf. Der frühere RPC Endpunkt beantwortet weiterhin Anfragen, kann jedoch jederzeit abgeschaltet werden.

Midnight ist eine Datenschutz Blockchain innerhalb des Cardano Ökosystems. Seine Smart Contracts können Bedingungen mithilfe von Zero Knowledge Proofs verifizieren, während sensible Eingaben privat bleiben. Anwendungen sind auf Netzwerkdienste angewiesen, um Blockchain Daten zu lesen, Vertragsaktivitäten zu verfolgen und Transaktionen einzureichen.

Node RPC übernimmt die Kommunikation mit dem Netzwerkknoten, einschließlich der Einreichung von Transaktionen. Der Indexer organisiert Blöcke, Transaktionen, Vertragszustand und Wallet bezogene Ereignisse, damit Anwendungen sie abrufen oder über Live Abonnements verfolgen können.

Blockfrost führt Authentifizierung und Nutzungsgrenzen ein

Blockfrost stellt gehostete Blockchain APIs bereit und ermöglicht Entwicklern Zugriff auf Netzwerkdaten und die Einreichung von Transaktionen, ohne die zugrunde liegende Infrastruktur selbst zu betreiben. Sein Midnight Dienst unterstützt GraphQL Abfragen und WebSocket Subscriptions neben Node RPC.

Der Zugriff erfordert ein Blockfrost Projekt, das speziell für Midnight Mainnet erstellt wurde. Jede Anfrage muss ihre project_id enthalten, entweder über einen HTTP Header oder einen URL Parameter. Anfragen ohne gültiges Token werden abgelehnt, und für andere Netzwerke ausgestellte Token können den Zugang zum Mainnet nicht authentifizieren.

Die Nutzung wird auf den eigenen Blockfrost Tarif der Anwendung angerechnet. Teams können einen zu ihrem Traffic passenden Tarif wählen oder einen eigenen Knoten und Indexer betreiben, was Midnight weiterhin unterstützt. Ein kostenpflichtiger Tarif ist nicht für jede Anwendung erforderlich.

Diese API Authentifizierung ist getrennt von der Finanzierung von Transaktionen. Midnight Transaktionen verbrauchen DUST, die Ressource, die durch registrierte NIGHT Token erzeugt wird.

Die Dokumentation warnt außerdem, dass im browserseitigen Code exponierte Token kopiert und gegen das Kontingent eines Projekts verwendet werden können. Sie beschreibt, wie Anfragen über ein Backend geleitet werden, das das Token auf dem Server hinzufügt, wenn Anwendungen es privat halten müssen.

Einige Wallets müssen ihren Synchronisationszustand eventuell neu aufbauen

Preview und Preprod behalten ihre von Midnight gehosteten Endpunkte ohne Projekt Authentifizierung. Der lokale Proof Server, der während der Generierung von Proofs private Eingaben verarbeitet, bleibt ebenfalls außerhalb des Dienstes von Blockfrost.

Für bestehende Mainnet Wallets kann die Migration über Verbindungseinstellungen hinausgehen. Das Service Desk Runbook von Midnight benennt ein Kompatibilitätsproblem, wenn eine Wallet einen gegen den früheren Indexer gespeicherten Synchronisationszustand wieder aufnimmt. Ereignis Kennungen und Transaktions Kennungen können sich zwischen Anbietern unterscheiden, sodass gespeicherte Verweise für den neuen Indexer ungeeignet sind.

Wallets, die bereits mit Blockfrost oder einem eigenen Indexer verbunden sind, sind von der Anbieteränderung nicht betroffen. Gleiches gilt für Wallets, die bei jedem Start ab Genesis synchronisieren, und für Anwendungen, die nur Vertragszustand lesen oder Transaktionen einreichen, ohne vom Indexer vergebene Kennungen zu speichern.

Wenn eine betroffene Wallet mit Fehlern stehenbleibt, die darauf hindeuten, dass Ereignisse außerhalb der Reihenfolge angewendet werden, empfiehlt das Runbook, den gespeicherten Synchronisationszustand zu verwerfen und ihn ab Genesis über den neuen Indexer neu aufzubauen.