Infura

Infura bietet verwalteten Zugang zu Blockchain-Nodes über RPC-APIs. Eine Anwendung kann den Zustand abfragen und Transaktionen senden, ohne für jedes Netzwerk einen eigenen Node zu betreiben. Die Verbindung zum MetaMask- und Consensys-Ökosystem bedeutet nicht, dass die Anwendung für die Nutzung des Dienstes auf eine bestimmte Wallet angewiesen ist.

Der Umfang der Integration wird je Netzwerk und Methode festgelegt. Historischer Zugriff, Subscriptions und Limits können je nach gebuchtem Leistungsumfang variieren. Vor der Wahl eines Endpoints wird geprüft, ob er die Operationen abdeckt, die das Produkt ausführen und abrufen muss.

Der Client nutzt einen Endpoint und dessen Zugangsdaten über HTTP oder die verfügbaren persistenten Verbindungen. Die Aufrufe folgen den vom Netzwerk unterstützten Schnittstellen. Einen Saldo abzufragen, Logs abzurufen und eine Transaktion zu senden verbraucht unterschiedliche Ressourcen und kann unterschiedlichen Limits unterliegen.

Die Anwendung legt Timeouts und Wiederholungen je Operation fest. Geht die Antwort auf einen Sendevorgang verloren, wird zuerst der zugehörige Hash oder Status geprüft, bevor eine Aktion mit Wirkung wiederholt wird. Bei Subscriptions geht die Wiederverbindung mit einem historischen Nachlesen einher, das die entstandene Lücke schließt.

Infura kann Teil eines Backends sein, das Bewegungen erfasst und EVM-Operationen vorbereitet. Der Dienst speichert Fortschrittsmarken und gleicht Daten mit der erforderlichen Blockreferenz ab. Diese Disziplin erlaubt es, nach einer Unterbrechung die Arbeit wieder aufzunehmen, ohne vorauszusetzen, dass jede Benachrichtigung genau einmal zugestellt wird.

Eine Architektur mit einem weiteren Anbieter kann die Abhängigkeit von einem einzigen Endpoint verringern. Vor dem Umschalten wird geprüft, dass beide im selben Netzwerk laufen und die erforderlichen Methoden und die nötige historische Tiefe unterstützen. Unterschiede bei Blockhöhe und Cache sind zu behandeln, damit keine widersprüchlichen Salden angezeigt oder Operationen mit inkompatiblen Daten erstellt werden.

Die Auslagerung von Nodes hebt die Verantwortung für Schlüssel, Berechtigungen und Geschäftslogik nicht auf. Zugangsdaten werden gemäß den verfügbaren Optionen eingeschränkt, und Server-Secrets werden nicht offengelegt. Eine Anwendung mit öffentlich sichtbaren Zugangsschlüsseln braucht Limits, die diesem Einsatz entsprechen, und darf nicht annehmen, dass der Browser sie vertraulich hält.

Pläne, Kontingente und unterstützte Netzwerke werden in der aktuellen Dokumentation geprüft. Der frühere IPFS-Dienst darf nicht mit dem heutigen RPC-Zugang verwechselt oder als Argument für neue Storage-Integrationen herangezogen werden. Die Wahl gegenüber anderen Anbietern hängt von gemessenen Fähigkeiten, Support und Kontinuität des Produkts ab.