💻 computer science

Validated Code Translation for Projects with External Libraries

Die Autoren stellen einen Rahmen vor, der durch API-Mapping und die Synthese von Adaptern für externe Bibliotheken die zuverlässige Übersetzung von Go-Projekten mit komplexen Abhängigkeiten nach Rust ermöglicht und dabei sowohl die Kompilierbarkeit als auch die semantische Äquivalenz signifikant verbessert.

Ursprüngliche Autoren: Hanliang Zhang, Arindam Sharma, Cristina David, Meng Wang, Brandon Paulsen, Daniel Kroening, Wenjia Ye, Taro Sekiyama

Veröffentlicht 2026-02-24

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Hanliang Zhang, Arindam Sharma, Cristina David, Meng Wang, Brandon Paulsen, Daniel Kroening, Wenjia Ye, Taro Sekiyama

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben ein riesiges, altes Haus aus Holz (das ist Ihr Go-Programm). Es ist solide, aber Sie möchten es in ein modernes, feuerfestes Stahlgebäude umwandeln (das ist Rust). Das Problem: Das alte Haus ist voller spezieller Möbel und Werkzeuge, die nur dort existieren. Wenn Sie das Haus einfach so abbauen und in Stahl neu aufbauen, wissen Sie nicht, wo die neuen Möbel hinpassen sollen, und Sie riskieren, dass das neue Gebäude einstürzt, weil wichtige Verbindungen fehlen.

Das ist genau das Problem, das dieses Forschungsprojekt löst. Hier ist die einfache Erklärung, wie die Forscher das geschafft haben:

1. Das Problem: Der "Halluzinierende" Architekt

Normalerweise nutzen Forscher künstliche Intelligenz (KI), um Code zu übersetzen. Man könnte sich die KI wie einen sehr talentierten, aber manchmal etwas verwirrten Architekten vorstellen.

Das Problem: Wenn das alte Haus (Go) spezielle Werkzeuge von externen Lieferanten nutzt, erfindet die KI oft neue, nicht existierende Werkzeuge für das neue Haus (Rust). Sie sagt: "Hier ist ein neuer Hammer!" – aber diesen Hammer gibt es im neuen Land gar nicht.
Das Ergebnis: Der neue Code funktioniert nicht, weil er auf Dinge verweist, die nicht existieren. Außerdem kann die KI oft nicht beweisen, dass das neue Haus genauso sicher ist wie das alte, besonders wenn die Möbel (Daten) sehr komplex und verschlossen sind.

2. Die Lösung: Ein zweistufiger Meisterplan

Die Forscher haben einen cleveren Trick entwickelt, der aus zwei Hauptteilen besteht:

Teil A: Der "Wissens-Bote" (RAG & Import-Lösung)

Statt der KI blind zu vertrauen, geben wir ihr einen Wissens-Boten an die Seite.

Wie es funktioniert: Bevor die KI den Code schreibt, schaut sie in eine riesige, gut organisierte Bibliothek (eine Datenbank aller verfügbaren Rust-Werkzeuge).
Die Analogie: Wenn die KI sieht, dass im alten Haus ein "Schlüsselbund" (Go-API) benutzt wird, fragt der Bot: "Welches Werkzeug im neuen Land passt dazu?" Der Bot findet den perfekten Ersatz und sagt der KI nicht nur den Namen, sondern auch genau, wie man ihn "herbeiruft" (welche Importe man braucht).
Der Effekt: Die KI erfindet keine Werkzeuge mehr. Sie nutzt nur die, die es wirklich gibt, und weiß genau, wo sie stehen. Das verhindert, dass das neue Gebäude ohne Fundament gebaut wird.

Teil B: Der "Übersetzer-Koffer" (Validierung mit Protobuf)

Jetzt haben wir einen Code, der vielleicht kompiliert, aber ist er auch richtig? Wie testen wir, ob das neue Stahlhaus genauso funktioniert wie das alte Holzhause, wenn die Möbel (Daten) so verschlossen sind, dass man sie nicht direkt vergleichen kann?

Das Problem: Sie können einen Go-"Schlüsselbund" nicht direkt in einen Rust-"Schlüsselbund" stecken. Sie sind zu unterschiedlich.
Die Lösung: Die Forscher bauen einen neutralen Koffer (eine Art Protobuf-Schema).
1. Sie nehmen das Go-Möbelstück und packen es in den Koffer.
2. Sie nehmen das Rust-Möbelstück und packen es in denselben Koffer.
3. Der Test: Wenn beide Möbelstücke in den Koffer passen und wieder herausgeholt werden können, ohne dass etwas kaputtgeht oder fehlt, wissen wir: Die Übersetzung ist korrekt!
Die Analogie: Stellen Sie sich vor, Sie wollen prüfen, ob zwei verschiedene Sprachen denselben Satz sagen. Sie schreiben den Satz auf einen neutralen Zettel (den Koffer). Wenn beide Sprachen den Zettel lesen und denselben Satz daraus machen, haben sie sich verstanden.

3. Das Ergebnis: Ein sicherer Umzug

Die Forscher haben dieses System an echten, komplexen Projekten getestet (wie Verschlüsselungs-Tools).

Ohne ihre Hilfe: Die KI scheiterte oft komplett (0 % Erfolg), weil sie die externen Werkzeuge nicht fand.
Mit ihrer Hilfe: Die Erfolgsrate stieg drastisch, in manchen Fällen auf 100 %.

Zusammenfassung in einem Satz

Die Forscher haben eine KI mit einem Wissens-Boten ausgestattet, damit sie keine falschen Werkzeuge erfindet, und einen neutralen Koffer gebaut, um zu beweisen, dass das übersetzte Programm genau das Gleiche tut wie das Original – selbst wenn es mit geheimnisvollen, verschlossenen Daten arbeitet.

Das ist wie ein Umzugsunternehmen, das nicht nur weiß, wo die neuen Möbel stehen, sondern auch garantiert, dass nichts beim Transport zerbricht.

Titel: Validierte Code-Übersetzung für Projekte mit externen Bibliotheken

Autoren: Hanliang Zhang, Arindam Sharma, Cristina David, Meng Wang, Brandon Paulsen, Daniel Kroening, Wenjia Ye, Taro Sekiyama
Affiliation: Amazon Inc., University of Bristol, National Institute of Informatics

1. Problemstellung

Die Übersetzung von Programmcode, insbesondere von Systemcode in speichersichere Sprachen wie Rust, ist eine wichtige Aufgabe. Große Sprachmodelle (LLMs) zeigen vielversprechende Ergebnisse bei der Generierung idiomatischen Codes. Allerdings stoßen bestehende Ansätze bei Projekten mit externen Abhängigkeiten an ihre Grenzen:

Halluzinationen von APIs: LLMs generieren häufig nicht-existierende Ziel-APIs oder verwenden falsche Bibliotheken, wenn der Quellcode externe Bibliotheken nutzt. Zudem versagen sie oft darin, die notwendigen Importe zu generieren, die den Aufruf von APIs erst ermöglichen (insbesondere in Rust, wo Traits und Re-Exports die Sichtbarkeit steuern).
Validierungsschwierigkeiten bei undurchsichtigen Typen: Die semantische Äquivalenz zwischen Quell- und Zielcode ist schwer zu validieren, wenn die Code-Logik auf undurchsichtigen (opaque) Typen externer Bibliotheken operiert.
- Viele Validierungstechniken setzen voraus, dass Eingabetypen strukturell identisch sind oder dass Felder direkt zugänglich sind.
- In modernen Sprachen sind Bibliothekstypen jedoch oft „opak" (private Felder) und können nur über spezifische öffentliche APIs konstruiert oder inspiziert werden.
- Ein direkter Datenaustausch zwischen Go und Rust ist ohne gemeinsame Laufzeit oder Wertrepräsentation nicht möglich.

2. Methodik

Die Autoren stellen einen Framework vor, das Go-Projekte mit externen Abhängigkeiten nach Rust übersetzt und die Korrektheit validiert. Der Ansatz besteht aus zwei Hauptphasen:

Phase 1: Cross-Language Library Mapping (RAG-basiert)

Um Halluzinationen zu reduzieren und korrekte Importe zu gewährleisten, wird ein Retrieval-Augmented Generation (RAG)-Ansatz verwendet:

Crate-Matching: Jedes Go-Paket wird einem entsprechenden Rust-Crate zugeordnet.
Wissensbasis (Knowledge Base): Für jedes Ziel-Crate wird eine strukturierte Wissensbasis erstellt, die öffentliche APIs, deren Dokumentation und gültige Importpfade enthält. Dies berücksichtigt komplexe Rust-Mechanismen wie Trait-Scopes und Re-Exports.
Abfrage und Retrieval: Bei der Übersetzung einer Go-Funktion wird die verwendete Go-API abgefragt. Das System sucht in der Wissensbasis nach semantisch ähnlichen Rust-APIs und liefert dem LLM nicht nur den API-Namen, sondern auch die notwendigen Import-Anweisungen (z. B. use sha2::{Sha512, Digest}).

Phase 2: Cross-Language Validierung mit undurchsichtigen Typen

Um die semantische Äquivalenz zu prüfen, ohne auf Feldzugriffe angewiesen zu sein, wird ein Schema-basierter Carrier-Ansatz verwendet:

Protobuf-Schema-Generierung: Ein LLM generiert ein sprachneutrales Protobuf-Schema ( $T_{Proto}$ ) basierend auf den Go-Typen.
Carrier-Typen: Der Protobuf-Compiler erzeugt daraus spezifische Carrier-Typen für Go ( $T^{Go}_{Proto}$ ) und Rust ( $T^{Rust}_{Proto}$ ). Diese Typen sind isomorph und dienen als gemeinsame Schnittstelle.
Adapter-Synthese: Anstatt Felder direkt zu kopieren, synthetisiert das System Adapter, die Werte über öffentliche Bibliotheks-APIs in den Carrier-Typ konvertieren und zurück.
- Go $\to$ Proto: Serialisierung via öffentlicher Methoden (z. B. Marshal).
- Proto $\to$ Rust: Deserialisierung via spezifischer Decoder (z. B. from_pkcs1_der).
Round-Trip-Validierung: Bevor die eigentliche Äquivalenz geprüft wird, wird sichergestellt, dass die Adapter verlustfrei funktionieren (d. h. $f^{-1}(f(v)) = v$ ). Dies bestätigt, dass das Schema alle relevanten Informationen enthält.
Differenzielle I/O-Validierung: Nach erfolgreicher Interoperabilität werden dieselben Testeingaben durch die Go-Quelle und die Rust-Übersetzung geschickt. Die Ausgaben werden über die Adapter verglichen. Falls sie übereinstimmen, gilt die Übersetzung als äquivalent für diese Eingaben.

3. Wichtige Beiträge

Erster Ansatz für externe Bibliotheken: Dies ist der erste Code-Übersetzungsansatz, der sowohl das Problem der API-Halluzination bei externen Bibliotheken als auch das Validierungsproblem bei undurchsichtigen Typen adressiert.
RAG-Architektur für Rust: Ein neuartiges Retrieval-System, das nicht nur API-Namen, sondern auch die komplexen Import-Strukturen von Rust (Traits, Re-Exports) berücksichtigt.
Adapter-basierte Validierung: Eine Methode zur Validierung von Funktionen mit undurchsichtigen Typen durch die Synthese von Adaptern, die ausschließlich öffentliche APIs nutzen, anstatt auf interne Strukturen zuzugreifen.
Modularität: Der Ansatz übersetzt Funktionen und Typen isoliert, nutzt aber eine globale Wissensbasis für die Konsistenz.

4. Ergebnisse

Das System wurde an six realen Go-Repositories mit nicht-trivialen externen Abhängigkeiten (u. a. Kryptographie-Bibliotheken wie age, pbkdf2, scrypt) evaluiert.

Kompilierungs- und Äquivalenzerfolg:
- Der durchschnittliche Erfolg bei der Kompilierung und der I/O-Äquivalenz liegt bei 95,83 %.
- Im komplexesten Fall (stark abhängig von Bibliotheken) wurde eine Steigerung von 100 % erreicht.
- Im Durchschnitt ist der Erfolg ca. 2-mal höher als bei Baseline-Ansätzen.
Ablationsstudie:
- Ohne RAG und Import-Auflösung („No RAG") scheitert die Übersetzung fast vollständig (0 % Erfolg bei Bibliotheksabhängigkeiten).
- Ohne Import-Auflösung („No Imports") scheitert der Code ebenfalls an Kompilierungsfehlern, obwohl die APIs korrekt benannt sind.
- Dies beweist, dass die korrekte Zuordnung von Importpfaden ebenso kritisch ist wie die API-Auswahl.
Vergleich mit Oxidizer: Der State-of-the-Art-Tool Oxidizer erreicht ohne RAG-Unterstützung bei diesen Projekten 0 % Erfolg, da es keine dynamische Bibliothekszuordnung vornimmt.

5. Bedeutung und Fazit

Die Arbeit demonstriert, dass die automatische Übersetzung von Systemcode in Rust auch für komplexe, bibliotheksabhängige Projekte machbar ist. Der Schlüssel liegt in der Kombination aus:

Präziser API-Zuordnung durch RAG, um Halluzinationen zu vermeiden.
Robuster Validierung durch die Umgehung von undurchsichtigen Typen mittels Protobuf-basierter Carrier und Adapter.

Dies ermöglicht es, die Sicherheit und Wartbarkeit von Legacy-Systemen (Go) durch Migration zu speichersicheren Sprachen (Rust) signifikant zu erhöhen, ohne dass manuelle Eingriffe bei der Validierung von Bibliotheksabhängigkeiten notwendig sind. Der Ansatz ist nicht auf Go/Rust beschränkt, sondern kann auf andere moderne Sprachpaare übertragen werden.