Ich habe viel über die Aktualisierbarkeit von Smart Contracts gelesen, und es scheint, dass die vorherrschende Praxis darin besteht, dass es im Allgemeinen eine gute Idee ist, die Vertragslogik von der Vertragsspeicherung getrennt zu halten, sodass es möglich ist, einen zu aktualisieren und nicht ändern zu müssen andere.
Meine Frage ist folgende: Erhöht die Tatsache, dass ein Vertrag einen anderen Vertrag kündigen muss, die Menge an Gas, die durch diese Logik ausgegeben wird. Nehmen wir zum Beispiel an, ich hätte einen Vertrag, der nach einer Zahl X gesucht und diese dann zur Zahl 5 hinzugefügt hat.
In einem Fall wird der Vertrag in X selbst gespeichert und kann daher direkt nachgeschlagen werden. Im anderen Fall ist ein separater Vertrag für die Speicherung von X verantwortlich, was dazu führt, dass ein Vertrag einen Funktionsaufruf macht, um X zu erhalten. Kostet einer mehr Gas? Wenn ja, kann man sagen, wie viel mehr?
Vielen Dank!
Ja, aber es ist ratsam, ein Profil gegen die Kompromisse der erhöhten Gaskosten mit der Aufrüstbarkeit zu erstellen, die es für Ihre Anwendung bietet.
Die meisten aktualisierbaren Verträge beinhalten Bibliotheken und den DELEGATECALL-Opcode, und einige der Kosten werden in einem Teil der Solidity-Dokumentation zu Bibliotheken beschrieben :
Bibliotheken können als implizite Basisverträge der Verträge angesehen werden, die sie verwenden. Sie werden in der Vererbungshierarchie nicht explizit sichtbar sein, aber Aufrufe von Bibliotheksfunktionen sehen genauso aus wie Aufrufe von Funktionen expliziter Basisverträge (Lf(), wenn L der Name der Bibliothek ist). Darüber hinaus sind interne Funktionen von Bibliotheken in allen Verträgen sichtbar, so als ob die Bibliothek ein Basisvertrag wäre. Natürlich verwenden Aufrufe interner Funktionen die interne Aufrufkonvention, was bedeutet, dass alle internen Typen übergeben werden können und Speichertypen als Referenz übergeben und nicht kopiert werden. Um dies in der EVM zu realisieren, wird der Code interner Bibliotheksfunktionen (und aller darin aufgerufenen Funktionen) in den aufrufenden Vertrag gezogen und anstelle eines DELEGATECALL ein regulärer JUMP-Aufruf verwendet.
Grundsätzlich kann, wenn alles in einem Vertrag steht, Referenzen verwendet, Kopien vermieden und der JUMP-Opcode verwendet werden.
Wenn es um externe Verträge geht, ist DELEGATECALL viel teurer als JUMP (derzeit 700 Gase gegenüber 10 Gasen), und es fallen weitere Kosten wie das Kopieren von Daten an.
Aber es ist wichtig, auch den konkreten Anwendungsfall zu profilieren und zu vergleichen. Für das oben angegebene einfache Beispiel wären die Kosten für einen CALL/DELEGATECALL überwältigend. In anderen Anwendungsfällen können sich diese zusätzlichen Gaskosten jedoch insgesamt viel geringer auswirken.
Ich würde sagen, ja, ein bisschen, aber nein, es ist in den meisten Fällen nicht besonders wichtig. Abgesehen von den einmaligen Bereitstellungskosten muss bei jeder Transaktion zusätzlicher Code ausgeführt werden. Es ist nicht kostenlos, aber der zusätzliche Code wird in den meisten Fällen nicht besonders teuer im Betrieb sein.
Sehen Sie sich die Gaskosten pro Vorgang an (ohne Gewährleistung): https://docs.google.com/spreadsheets/d/15wghZr-Z6sRSMdmRmhls9dVXTOpxKy8Y64oy9MvDZEQ/edit#gid=0 .
Eine grundlegende Heuristik ist, dass Zustandsänderungs-Opcodes (z. B. SSTORE) im Vergleich zu Compute-Opcodes, die die Blockchain nicht ändern, ziemlich hoch sind. Man kann im Allgemeinen zusätzliche kostengünstige Overhead-Schritte hinzufügen (z. B. Nachschlagen einer Vertragsadresse und Bilden einer Nachricht), ohne die Gesamtkosten einer Zustandsänderung stark zu erhöhen. Teuer wird der Zustandswechsel in jedem Fall.
Lesevorgänge werden oft mit konstanten Funktionen oder Ortsgesprächen abgewickelt, die überhaupt kein Gas verbrauchen . Daher beschränken sich Bedenken hinsichtlich der Transaktionskosten im Allgemeinen auf Transaktionen, die zu einer Zustandsänderung führen. Erstellen/Einfügen, Aktualisieren und Löschen sind also mit Kosten verbunden (der Löwenanteil von Operationen wie SSTORE). Reads sind in der Regel kostenlos, unabhängig von der Komplexität. Bedenken Sie auch, dass viele Systeme Offchain-Speicher verwenden, der von Event-Emittern gespeist wird, die aus Leistungsgründen eine Kopie „offizieller“ Fakten aufbewahren. Ein weiteres Beispiel für eine Situation, in der es überhaupt nur um die Kosten für Updates geht.
Um mit einem bestimmten Beispiel herumzuspielen und die Kosten zu vergleichen, könnten Sie erwägen, repräsentative Funktionen in beide Richtungen zu kodieren und den tatsächlichen Gasverbrauch zu vergleichen. Der Solidity Realtime-Compiler zeigt den Bytecode nach der Kompilierung an. Sie können den Quellcode überspringen, um zu sehen, welche tatsächlichen Schritte "teuer" sind, und entsprechend optimieren.
Beachten Sie als Fußnote die versteckten Kosten zusätzlicher Komplexität. Während aktualisierbare Verträge in vielerlei Hinsicht vorteilhaft sind, gibt es eine Yin-Yan-ähnliche Reihe von Kompromissen, die für jeden Anwendungsfall berücksichtigt werden müssen. Zum Beispiel könnte die Aufrüstbarkeit in einigen Fällen die Vertrauenswürdigkeit verringern und ist möglicherweise eine neue Fehlerquelle.
Hoffe es ist hilfreich.
Rob Hitchens
eth