ens-contracts: Die Vertragsbausteine hinter ENS und ihr Releaseweg
Die Kernverträge des ENS-Protokolls. DNSResolver = Für das Hosten von DNS-Domänen auf der Ethereum-Blockchain über ENS ist experimentelle Unterstützung verfügbar.
Auf einen Blick
- Was ist das?
- ensdomains/ens-contracts bündelt Registry, .eth-Registrar, Resolver, Tests und Deployment-Hilfen für das Ethereum Name Service Ökosystem.
- Für wen ist es gedacht?
- Das Repository ist für Entwickler geeignet, die ENS-Verträge, Tests oder Releases nachvollziehen müssen. Es ist keine vollständige Sicherheitsbewertung und kein Nachweis aktueller L2-Deployments.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Repository für zentrale ENS-Verträge
ensdomains/ens-contracts enthält die zentralen Smart Contracts des ENS-Protokolls. Das Projekt wird in TypeScript entwickelt, stellt sich zugleich als npm-Paket dar und kann kompilierte JSON-Verträge bereitstellen. Die vollständige Systemdokumentation liegt laut README unter docs.ens.domains. Damit liegt der Schwerpunkt dieses Repositorys auf Implementierung, Tests, Deployment und Veröffentlichung. Wer nur die fachliche Erklärung von ENS sucht, braucht die externe Dokumentation. Wer eine konkrete ABI oder einen Releaseprozess nachvollziehen will, muss in dieses Repository und seine Branches schauen. Dieser Abschnitt ordnet das konkrete Projekt ein. Die Aussage bezieht sich auf das README und nicht auf eine allgemeine Kategorie. Für die lokale Prüfung sind die genannten Namen, Befehle und Pfade maßgeblich. Abweichungen der Umgebung müssen als Ergebnis dokumentiert werden. Das schützt vor einer Bewertung, die nur aus einem kurzen Werbesatz entsteht. Maintainer, Nutzer und Betreiber haben dabei verschiedene Fragen: Der Entwickler braucht den Build, der Betreiber braucht die Konfiguration, und der Nutzer braucht eine nachvollziehbare Funktion. Die vorliegenden Materialien beantworten diese Fragen unterschiedlich vollständig. Genau diese Grenze gehört zur technischen Einordnung.
Die Registry als Auflösungsbasis
Die Registry verwaltet Domains mit Besitzer, Resolver und TTL. Dazu gehören das ENS-Interface und ENSRegistry sowie ENSRegistryWithFallback für die Architektur nach der Migration von 2020. FIFSRegistrar vergibt Subdomains nach dem First-come-first-served-Prinzip. ReverseRegistrar unterstützt Rückwärtsauflösung, während TestRegistrar für Testnetze vorgesehen ist und beanspruchte Namen nach 28 Tagen verfallen lässt. Diese Aufteilung macht sichtbar, dass Namensbesitz, Auflösung und Testbetrieb eigene Vertragsrollen haben. Für eine Integration sollte man nicht nur die Registry-Adresse übernehmen, sondern auch prüfen, welcher Resolver und welches Registrar-Modell im Zielnetz verwendet werden.
.eth mit Commit-Reveal und Oracles
BaseRegistrar verwaltet die .eth-TLD und unterstützt Controller, Registrierung, Verlängerung, Übertragung und Rückforderung. Der EthRegistrarController nutzt Commit-Reveal, um Frontrunning beim Registrieren zu erschweren. Er kann ein Preis-Oracle setzen und erlaubt Verlängerungen. StablePriceOracle berechnet Preise aus Namenslänge und Fiat-Oracle; SimplePriceOracle liefert einen festen Jahrespreis. Das README erläutert die Rollen und die beiden Preiswege, nennt aber nicht die Konstruktorparameter von SimplePriceOracle. Wer Kosten oder Registrierungsabläufe in eine Anwendung übernimmt, muss diese Parameter und die aktuelle Deployment-Konfiguration aus den konkreten Verträgen und Netzwerkinformationen abgleichen.
Resolver orientieren sich an EIPs
PublicResolver bündelt mehrere Resolver-Funktionen. Genannt werden ABIResolver nach EIP-205, AddrResolver nach EIP-137 und EIP-2304, ContentHashResolver nach EIP-1577, DataResolver nach ENSIP-24, InterfaceResolver nach EIP-165, NameResolver nach EIP-181, PubkeyResolver nach EIP-619 und TextResolver nach EIP-634. Diese Zuordnung ist nützlich, weil sie die erwarteten Datenarten mit bekannten Schnittstellen verbindet. Experimentelle DNS-Unterstützung ist ebenfalls vorhanden, wird aber auf alte ENS-Dokumentation verwiesen. Der genaue Status dieser Funktion bleibt deshalb offen und sollte nicht allein aus dem Dateinamen abgeleitet werden.
L2ReverseRegistrar und einheitliche Adressen
L2ReverseRegistrar ist laut README der einzige Vertrag dieses Repositorys, der auf L2-Netzwerken bereitgestellt wird. Er hängt von UniversalSigValidator ab und soll Signaturen über mehrere L2s hinweg nutzbar machen. Eine einheitliche Vertragsadresse wird über Safe und einen CREATE3-Helfervertrag angestrebt. Das README listet Safe-Adressen für Testnetze und Mainnet, sagt aber nicht, auf welchem L2 der Vertrag aktuell tatsächlich aktiv ist. Diese Lücke ist für jede Integration relevant: Vor einer Transaktion muss die Adresse im Zielnetz on-chain geprüft und mit dem passenden Release abgeglichen werden.
Bun, Tests und Prettier-Hook
Der Entwicklerleitfaden verwendet bun als Paketmanager. Die dokumentierten Befehle sind bun i für Abhängigkeiten, bun run test für Tests und bun run pub für die Veröffentlichung. Ein Husky-Pre-Commit-Hook formatiert Vertragsdateien mit Prettier; neue Pfade müssen in das Formatierungsskript aufgenommen werden. Deployment-Tests können mit einem Anvil-Fork oder einem Tenderly Virtual TestNet erfolgen. Ein Impersonation-Skript unterstützt Deployments ohne Zugriff auf das Owner-Konto. Diese Befehle bilden einen konkreten Prüfpfad, aber sie ersetzen keinen Auditbericht. Das Repository enthält laut Baseline keinen eigenständigen Audit- oder Performance-Nachweis.
Staging, Mainnet und MIT
Der Releaseprozess beginnt auf staging. Nach Testnet- und Mainnet-Deployments werden Feature-Änderungen nach main gemergt. Semantische Versionierung, Release Candidates sowie Testnet- und Mainnet-Tags strukturieren den Ablauf. Beschrieben werden normale, Cherry-pick- und Notfall-Releases. Die zentrale Regel lautet, dass der auf Mainnet bereitgestellte Code dem Quellcode des Mainnet-Releases entsprechen muss. Die Metadaten nennen MIT. Für eine Weitergabe oder Einbindung ist daher der MIT-Lizenztext zusammen mit den eigenen Vertrags- und Deploymentbedingungen zu prüfen. Lizenz und On-chain-Sicherheit sind getrennte Fragen.
Redaktionelles Fazit
Das Repository ist für Entwickler geeignet, die ENS-Verträge, Tests oder Releases nachvollziehen müssen. Es ist keine vollständige Sicherheitsbewertung und kein Nachweis aktueller L2-Deployments. Vor einer Integration sollten bun run test, die betroffenen Solidity-Verträge und die on-chain Adresse des gewünschten L2 gemeinsam geprüft werden. Für ENS sollte die Prüfung den konkreten Release-Tag, die ABI, bun run test und die Zielnetzwerk-Adresse festhalten. Beim Commit-Reveal sind Ablauf und Frist getrennt vom Preis-Oracle zu testen. Beim L2ReverseRegistrar muss der Contract tatsächlich auf dem betreffenden L2 gefunden werden. Ein erfolgreicher Test im Anvil-Fork beweist keine Mainnet-Bereitstellung, und ein Release-Tag ersetzt keine Prüfung der on-chain Bytecodes.
Community-Notizen