News
Algorand 5.0: AVM v13 bringt flexiblen Box-Zugriff und neue Sicherheitsregeln für Smart Contracts
Von KryptoRatgeber · veröffentlicht 24. August 2026
Mit dem Algorand-5.0-Upgrade hat die Algorand Foundation am 24. August 2026 in einem Entwicklerblog-Beitrag von Brian Whippo erläutert, wie die neue Version 13 der Algorand Virtual Machine den Datenaustausch zwischen Smart Contracts grundlegend flexibler gestaltet — ohne dabei bewährte Sicherheitsmechanismen aufzugeben. Bislang waren die sogenannten Box-Speicher einer App hermetisch von allen anderen Anwendungen abgeriegelt; künftig können bestimmte Apps unter definierten Bedingungen lesend oder schreibend darauf zugreifen. Für Anleger und Entwickler ist das relevant, weil solche Architekturentscheidungen direkt bestimmen, wie sicher und wie leistungsfähig komplexe Anwendungen auf einer Blockchain sein können.
Zwei neue Zugriffsebenen — und eine absichtlich eingebaute Bremse
Der Algorand Foundation Blog-Beitrag von Brian Whippo beschreibt zwei neue Anwendungsparameter, die das Herzstück der Neuerung bilden: FamilyBoxAccess und ForeignBoxReads.
FamilyBoxAccess gewährt Apps, die dieselbe Creator-Adresse teilen — also aus derselben "Familie" stammen —, sowohl Lese- als auch Schreibzugriff auf die Box-Daten dieser Gruppe. ForeignBoxReads hingegen erlaubt völlig fremden Apps ausschließlich den Lesezugriff; schreiben dürfen sie nicht. Diese Unterscheidung ist sicherheitsrelevant: Wer Daten nur lesen, aber nicht verändern kann, richtet im Schadensfall weniger Schaden an.
Hinzu kommt ein neuer Mechanismus namens app_params_set — ein Befehl, mit dem eine Anwendung bestimmte eigene Parameter nachträglich anpassen kann. Das erfordert zwei Schritte: erst ein Code-Update, dann die tatsächliche Ausführung. Apps, die von vornherein unveränderlich gebaut wurden, bleiben davon unberührt.
Eine zusätzliche Schutzregel greift bei Schreibzugriffen innerhalb einer Familie: Schaltet sich zwischen zwei solchen Zugriffen eine App aus einer anderen Familie ein, bricht der AVM — die virtuelle Maschine, die Smart Contracts auf Algorand ausführt — den gesamten Vorgang ab. Das verhindert, dass Dritte den Prozess manipulieren, bevor er abgeschlossen ist.
Warum Algorands Sicherheitsarchitektur den Unterschied macht
Das Interessante an diesen technischen Änderungen ist nicht, was sie ermöglichen — sondern was sie bewusst ausschließen. Viele der teuersten Hacks in der Geschichte dezentraler Anwendungen gehen auf einen einzigen Konstruktionsfehler zurück: Reentrancy-Angriffe, bei denen ein böswilliger Contract mitten in einer laufenden Transaktion erneut aufgerufen wird und dabei Geld abzieht, bevor Guthaben aktualisiert werden. Der AVM verbietet solche Schleifen seit seiner Einführung grundsätzlich — und AVM v13 bricht mit dieser Regel an keiner Stelle.
Das ist keine Selbstverständlichkeit. Flexiblerer Datenaustausch zwischen Anwendungen könnte theoretisch neue Angriffsflächen schaffen, wenn er schlecht umgesetzt wird. Algorands Lösung: eine Schutzregel, die den gesamten Aufruf abbricht, sobald eine App von außerhalb der Gruppe zwischen zwei Schreibzugriffe tritt. Das klingt technisch, hat aber eine einfache Konsequenz — Entwickler erhalten Flexibilität, ohne dass das System ihnen erlaubt, versehentlich unsichere Muster zu bauen.
Für Anleger bedeutet das: Sicherheit auf Protokollebene ist kein Marketing-Versprechen, sondern lässt sich an konkreten Designentscheidungen ablesen. Kein Smart Contract Audit kann Fehler korrigieren, die das zugrunde liegende Protokoll strukturell zulässt.
Ein Vorbehalt bleibt: Wer von den neuen Möglichkeiten profitieren möchte, muss seine Anwendung aktiv anpassen. Bestehende, unveränderliche Contracts bleiben unberührt — was Stabilität bedeutet, aber auch, dass die Neuerungen nicht automatisch der gesamten Algorand-Ökosphäre zugutekommen.
Warum isolierte App-Daten bislang Standard waren — und was das ändert
In der Blockchain-Welt speichern Smart Contracts — selbstausführende Programme ohne Mittelsmänner — ihre Daten oft in zugewiesenen Speicherbereichen. Bei Algorand heißen diese Bereiche „Boxes": kleine, abgeschlossene Datenfächer, die exklusiv einer einzigen Anwendung gehören. Der Vorteil dieser Abschottung war Einfachheit und klare Verantwortlichkeit — keine andere App konnte versehentlich oder böswillig in fremde Daten eingreifen.
Dieses strikte Modell stößt jedoch an Grenzen, sobald Entwickler mehrere Apps miteinander verzahnen wollen — etwa für modulare Protokolle, bei denen verschiedene Programmteile gemeinsam auf denselben Datenbestand zugreifen müssen. Gleichzeitig lauert bei solchen Öffnungen eine klassische Gefahr: der Reentrancy-Angriff, bei dem ein bösartiger Contract einen anderen mitten in einer Transaktion erneut aufruft und so Gelder mehrfach abzieht. AVM v13 adressiert genau dieses Spannungsfeld.
Häufige Fragen
Müssen bestehende Algorand-Apps automatisch aktualisiert werden?
Nein. Die neuen Box-Zugriffsfunktionen aus AVM v13 sind kein automatisches Update für laufende Anwendungen. Entwickler müssen ihre Apps aktiv anpassen und die neuen Opcodes gezielt einbauen. Wer eine App von vornherein als unveränderlich konzipiert hat, kann diese Funktionen gar nicht nachträglich aktivieren — was im Umkehrschluss bedeutet: Solche Apps bleiben exakt so, wie sie waren.
Was unterscheidet Familien-Lesezugriff von Familien-Schreibzugriff?
Der Unterschied ist sicherheitsrelevant: FamilyBoxAccess erlaubt Apps derselben Creator-Adresse sowohl das Lesen als auch das Schreiben auf gemeinsam genutzte Box-Daten. ForeignBoxReads hingegen gewährt beliebigen fremden Apps ausschließlich Lesezugriff — keinerlei Schreibrechte. Eine fremde App kann also Daten einsehen, aber nicht verändern.
Was ist ein Reentrancy-Angriff, und warum spielt er hier eine Rolle?
Ein Reentrancy-Angriff beschreibt eine Angriffsmethode, bei der ein Smart Contract während seiner Ausführung erneut aufgerufen wird — oft, um Gelder mehrfach abzuziehen, bevor die ursprüngliche Transaktion abgeschlossen ist. Der AVM verbietet solche Rückschleifen grundsätzlich; daran ändert auch AVM v13 nichts.