Internet Computer

Internet Computer erweitert den Einsatz von Smart Contracts auf Anwendungen, die Logik und Daten in Canistern halten. Jeder Canister hat eine Identität und ein Programm, das Methoden zur Interaktion mit seinem Zustand bereitstellt. Entwickelt werden kann in Sprachen wie Motoko oder Rust.

Für ein Produkt hängt der Umfang davon ab, welche Teile des Backends im Netzwerk laufen müssen. Diese Entscheidung richtet sich nach Anforderungen an Verifizierbarkeit, Kontrolle und Verfügbarkeit. Die gesamte Anwendung on-chain zu betreiben ist kein Selbstzweck, wenn es Komplexität hinzufügt, ohne einem konkreten Bedarf zu dienen.

Canister führen WebAssembly-Code aus und kommunizieren über Nachrichten. Die Anwendung unterscheidet Leseoperationen und Zustandsänderungen sowie Aufrufe, die mehrere Komponenten durchlaufen. Ihr Ressourcenverbrauch wird mit Cycles finanziert.

Das Design muss die Persistenz während eines Updates, die Administrationsrechte und das Verhalten bei verspäteten Antworten oder Fehlern anderer Canister berücksichtigen. Ein verteilter Ablauf entspricht nicht einer einzelnen Datenbankoperation. Jede Stufe und ihre Kompensationen sollten modelliert werden, bevor das Backend in mehrere On-Chain-Dienste aufgeteilt wird.

Ein Canister hält Zustand und stellt Methoden bereit, die ihn abfragen oder ändern. Update-Aufrufe durchlaufen das Konsensprotokoll; Queries nehmen einen anderen Weg, und ihre Verifizierung muss je nach ausgelieferten Daten entworfen werden. Die Kommunikation zwischen Canistern bringt Wartepunkte und mögliche Fehler mit sich, die die Anwendung explizit behandeln muss.

Internet Computer kann sich eignen, wenn ein Produkt bestimmte Regeln und Daten innerhalb einer Blockchain-Infrastruktur ausführen muss. Es erlaubt, gemeinsame Register, programmierbare Dienste und Anwendungen mit Komponenten zu evaluieren, die sich außerhalb eines konventionellen Servers verifizieren lassen müssen.

Bei Metlabs grenzt die Evaluierung ab, welcher Code in den Canister geht und welche externen Systeme bestehen bleiben. Danach werden Authentifizierung, Ressourcenverbrauch und Wiederherstellung des Zustands getestet. Das Betriebsbudget umfasst Update-Zyklen und das Monitoring des Cycles-Guthabens, nicht nur das anfängliche Schreiben des Programms.

Eine Dokumentenanwendung kann ihre Logik in Canistern halten und Teile ihrer Oberfläche daraus ausliefern. Der Betriebsplan umfasst ein Cycles-Guthaben zur Finanzierung der Ressourcen, Kontrollen darüber, wer den Code aktualisieren darf, und den Erhalt des Zustands während eines Updates. Getestet wird auch, wie eine Operation weiterläuft, wenn ein Aufruf zwischen Komponenten fehlschlägt. Die Einbindung externer Daten oder Vermögenswerte beseitigt diese Abhängigkeiten nicht, auch wenn der Kern der Anwendung im Netzwerk läuft.

Das Modell erfordert andere Kenntnisse als ein traditionelles Backend oder eine Solidity-dApp. Aufrufe zwischen Komponenten, Speicherverwaltung und Updates brauchen spezifische Tests. Ebenso zählt, wer einen Canister kontrolliert und unter welchen Bedingungen er ihn ändern kann.

Eine konventionelle Anwendung, die Nachweise in einem anderen Netzwerk verankert, kann einfacher sein, wenn nur einige Meilensteine verifiziert werden müssen. Der Vergleich muss davon ausgehen, welche Garantien das Produkt verlangt. Rechenleistung ohne Begründung dieser Garantien ins Netzwerk zu verlagern kann die Wartungskosten erhöhen, ohne ein zusätzliches Problem zu lösen.