Ich werde verspottet, weil ich den Leuten sage, dass Klartext-Private Keys schlecht sind. Aber hier sind wir im Jahr 2026, und ich kämpfe immer noch gegen Leute, die sagen, es sei in Ordnung, dies zu tun, während Schlüssel-Leaks die #1 Quelle für Hacks im letzten Jahr waren. Lass mich die häufigsten Gegenargumente erklären, die ich bekomme, und warum sie falsch sind. 👇

1. „Es ist nur mein Bereitstellungsschlüssel, nicht mein Administrationsschlüssel“ Eine bewährte Praxis für die Entwicklung von Smart Contracts besteht darin, das Eigentum an einem Smart Contract an eine andere Wallet zu übertragen als die, mit der Sie ihn bereitgestellt haben. Wir empfehlen, Bereitstellungsskripte in den Umfang einer Prüfung aufzunehmen, um dies zu überprüfen.

Ein Wegwerf-Wallet wie dieses zu haben, ist eine gute Sache, aber es macht dich trotzdem angreifbar: - Deployer-Adressen werden oft auf Explorern gekennzeichnet, um Glaubwürdigkeit zu verleihen - Du hast immer noch Geld darin, das gestohlen werden könnte - Wir haben viele Angriffe gesehen, bei denen jemand vergessen hat, das Eigentum zu übertragen

Ich war bei Warroom-Anrufen, bei denen die Antwort lautete: „Der Deployer-Schlüssel war der Admin, und er wurde geleakt“. Die meisten Projekte lassen ihre Deployment-Skripte nicht auditiert. Also wenn du sagst „es sind nur meine Deployment-Schlüssel“, sage ich „du hast dein Deployment nicht auditiert, du wirst es vermasseln“

Und schließlich, wenn du Deployment-Keys in einer .env verwendest, gewöhnst du dich daran, mit Klartext-Keys umzugehen. Denk daran: "Was du in der Entwicklung übst, wirst du in der Produktion tun" Und wenn du Klartext-private Keys hast, wette ich, dass du sowieso nicht vorsichtig bist.

2. „Ich benutze eine .gitignore, ich werde es nicht ins Quellverzeichnis pushen“ Schreckliche Erwiderung. React, solana/web3js und npm wurden letztes Jahr alle gehackt, und einige der Hacks haben alle deine Dateien nach sensiblen Informationen in .env-Dateien durchsucht. Wenn du „npm install“ ausgeführt hast - hättest du in Schwierigkeiten geraten können.

Ganz zu schweigen von den bösartigen IDE-Erweiterungen und anderer Malware, die Sie installieren könnten und die ebenfalls durch Ihre Dateien geht. Die Leute mit diesem Einwand sagen auch normalerweise: „Ich bin kein Anfänger, ich werde vorsichtig sein“, aber offensichtlich verstehen sie nicht, wie die Software-Lieferkette funktioniert.

3. „Es ist zu umständlich, es ist einfach bequemer, Klartextschlüssel zu verwenden“ Nun, das Leben ist bequemer, wenn man $0 hat, man muss sich keine Sorgen machen, sein Geld sicher zu halten, wenn man kein Geld hat. Ich denke, das ist ein guter Punkt.

Aber im Ernst, es gibt Dinge, die du tun kannst. Die meisten Frameworks für Smart-Contract-Entwicklung haben Verschlüsselungstools, wie Foundry, Moccasin und Hardhat. Alle ermöglichen es dir, deine Schlüssel mit einem einzigen Befehl zu verschlüsseln und mit einem Passwort beim Ausführen des Skripts zu entschlüsseln. Es ist sehr praktisch.

Alles, was ich bitte, ist, dass wir keine unverschlüsselten privaten Schlüssel normalisieren. Ihr bekommt nicht die DMs, die ich und SEAL von denen erhalten, die alles verloren haben. Der Schmerz ist echt, normalisiert ihn nicht. LLMs werden auf dieser schlechten Praxis trainiert und empfehlen sie immer noch, wir müssen aufhören, damit LLMs aufhören.