Bereitstellungen auf Ebene 1

Es gibt mehrere Möglichkeiten, Smart Contracts einzusetzen, wie viele. Es hängt alles von den Vorlieben einer Person ab. Lassen Sie uns über die 2-3 wichtigsten Ansätze sprechen, die die meisten Entwickler meiner Meinung nach gerne anwenden:

1. Hardat — Es ist eine Entwicklungsumgebung, die speziell für Ethereum entwickelt wurde. Mit Smart Contracts kann man verschiedene Dinge tun, wie Debuggen, Testen und Bereitstellungen. Es ist einfach zu bedienen, hat eine eigene CLI und verwendet Javascript, eine ziemlich verbreitete Sprache, die fast jedem in der Branche bekannt ist.

2. Foundry - Es ist eine weitere beliebte Waffe, die Entwickler normalerweise für ihre Smart-Contract-Entwicklung bevorzugen. Es wurde in letzter Zeit populär, weil es Solidity für alles verwendet, was bedeutet, dass Sie für den Entwicklungsteil nicht in verschiedene Sprachen wechseln müssen. Sie wissen schon, Solidity, Sie haben alles. Und ja, es ist auch mit CLI ausgestattet und könnte im Vergleich zu Hardhat ziemlich schwierig sein. Dieser Schmerz ist es jedoch wert.

3. Remix (Sie müssen den Link nicht einfügen) - Sie kennen Remix, das erste Tool, das uns vorgestellt wird. Nun ja, es ist das einfachste, aber andere Dinge als Bereitstellungen zu erledigen, könnte schwierig genug sein. Dennoch habe ich nie gesehen, dass Entwickler es häufig für ernsthafte Entwicklungszwecke verwendet haben. Sogar ich habe es manchmal verwendet, um sehr grundlegende Dinge zu testen, wo ich einen Vertrag abschließen muss, um einige seiner Teile zu testen, anstatt dafür ein ganzes Skript zu schreiben.

Daneben finden Sie einige andere Tools, die heutzutage ziemlich altmodisch geworden sind. Ich erinnere mich, dass es Anfang 2023 Tools wie Truffle gab, die mir ehrlich gesagt nicht gefallen haben (nur eine persönliche Meinung).

Es gibt noch ein anderes Tool, das ich persönlich kenne und das anderen nicht viel bekannt ist, weil es vorerst eine Art Starter ist, entwickelt von einem kleinen Team und ich kenne den Gründer (ich war einer der ersten Leute, mit denen er seine Idee geteilt hat). Es ist AnyFlow. Dieses Projekt wurde eigentlich entwickelt, um die Probleme zu vermeiden, die Entwickler manchmal während der Entwicklung intelligenter Verträge haben. Einige seiner Funktionen sind:

• Sie müssen sich nicht um Testnet-Token kümmern
• Tolle Benutzeroberfläche
• Kein Clip

Die einzige Voraussetzung für AnyFlow ist, dass Ihr Projekt ein Hardhat-Projekt sein muss (das mit nur einem einzigen Befehl erstellt wird). Dann müssen Sie nur noch Ihren GitHub verbinden, Ihr Repo aufrufen, die Ketten auswählen und bereitstellen. Ich habe es persönlich ausprobiert, war absolut gut, besonders wenn Sie nur noch wenige Testnet-Token haben.

---

Lassen Sie uns nun einige Ihrer spezifischen Fragen beantworten:

Was ist das Best-Practice-Verfahren für die Bereitstellung eines DeFi-Protokolls in einem beliebigen Layer-1- oder 2-Netzwerk?

Egal, ob es sich um ein DeFi-Protokoll oder eine Reihe miteinander verknüpfter intelligenter Verträge handelt, das Verfahren bleibt die meiste Zeit das gleiche. Testen Sie den Vertrag, stellen Sie ihn bereit und schützen Sie Ihre privaten Schlüssel (versuchen Sie, einen besseren Weg zu finden, anstatt Ihre Schlüssel in einer .envDatei zu speichern. Außerdem ist es eine gute Praxis, deine Entwickler-Wallets und die Wallets mit den tatsächlichen Geldern getrennt aufzubewahren. Warum so? Aufgrund der vielen Hacks, die in diesen Tagen stattgefunden haben und die Ziele sind wir, wir Entwickler. Ich war bereits mit einem Angriff konfrontiert, wurde aber irgendwie gerettet (du kennst den Grund), aber viele haben nicht immer so viel Glück.

Verwenden Sie Remix, verwenden Sie eine CLI oder eine andere Alternative? Ist einer von ihnen sicherer als der andere? und warum wird dieses Verfahren gegen die anderen 2 gewählt?

Den ersten Teil habe ich bereits beantwortet. Apropos Sicherheit, ich habe nie wirklich von einer Sicherheitslücke oder Sicherheitslücke gehört, wenn es um die Bereitstellung geht (es sei denn, es liegt selbst ein Entwicklerfehler vor, z. B. hat er versehentlich seinen privaten Schlüssel an Github weitergegeben usw.). Daher sind die meisten von ihnen sicher. Die Wahl eines von ihnen ist Ihre persönliche Präferenz. Warum probieren Sie nicht alle aus und wählen Sie einfach das aus, mit dem Sie sich wohl fühlen?

Als das Uniswap-Team beispielsweise den Uniswap-Code in Ethereum-Layer 1 implementierte, wie haben sie den Code bereitgestellt?

Ich weiß nicht genau, was das Uniswap-Team für die Bereitstellung von Uniswap verwendet hat. Wahrscheinlich kann es sofort über Google oder ein bisschen in verschiedenen Artikeln oder auf GitHub von Uniswap selbst gesucht werden. Ehrlich gesagt spielt es keine große Rolle. Sobald Sie die Dinge rund um den Einsatz intelligenter Verträge genau kennen, werden Sie wahrscheinlich erraten, wie sie das gemacht haben (wenn nicht sogar genau). Der Punkt, auf den Sie sich hier konzentrieren sollten, ist, wie sie es geschrieben und getestet haben, aber das liegt an Ihnen. Ich bin mir jedoch definitiv sicher, dass sie Remix nicht verwendet haben.

Viel Glück!