So richten Sie die Zugriffskontrolle für Smart Contracts ein

Wenn man versucht, zwischen Web2 und Web3 zu unterscheiden, ist das Konzept des Eigentums ein Schlüsselwert, der die beiden unterscheidet.

Einfach ausgedrückt: Was Sie erstellen, ist das, was Sie besitzen und was Sie monetarisieren können. So wie es sein sollte. Nicht weniger, nicht mehr. Tatsächlich ist der Tag, an dem Sie Ihr erstes NFT prägen, der, an dem Sie es dank der Unveränderlichkeit der Blockchain als Eigentümer in Web3 erstellt haben. Wenn überhaupt, ist das Gefühl, beschützt zu sein, unbezahlbar.

Apropos: Dieses Eigentumskonzept ist für Smart Contracts im Hinblick auf zugängliche Funktionen und zulässige Zustandsänderungen ebenso wichtig.

Ihr erster Blick auf Eigentum mit Smart Contracts

Warum ist es also wichtig, dass Sie den von Ihnen geschriebenen Smart Contract „besitzen“?

Denken Sie darüber nach: Wenn Sie ein Fahrrad hätten, würden Sie zögern, Eigentumsnachweise zu führen? Nur für den Fall, dass jemand es gestohlen und für schändliche Zwecke verwendet hat? Natürlich nicht.

Aus demselben Grund möchten Sie nachweisen, dass Sie Eigentümer eines NFT oder eines Smart Contracts sind. Nun ja, vielleicht verschafft sich doch jemand unbefugten Zugriff und profitiert finanziell davon, oder?

Nehmen wir an, Sie arbeiten mit Dunzo zusammen und haben diesen intelligenten Vertrag geschrieben, in dem Sie den Paketpreis zuzüglich Versandkosten festlegen und angeben können, ob dieser vom Käufer bezahlt wurde oder nicht.

Im Idealfall können Sie den Namen des Käufers, den Gesamtpreis des Pakets und der Lieferung auf einen bestimmten Betrag festlegen und setPackageDelivered auf true setzen. Sobald Sie mit der Zustellung des Pakets fertig sind, versteht sich.

Aber wie wir alle wissen, läuft nie etwas nach Plan.

Was wäre nun, wenn der Käufer Zugriff auf die Vertragsfunktionen und die Möglichkeit hätte, den packageDelivered-Wert auf „false“ zurückzusetzen oder den packageDeliveryPrice-Wert in einen niedrigeren Wert zu ändern? Sie können nicht nur weniger für das Produkt bezahlen, sondern auch überhaupt nichts bezahlen.

Natürlich sollte außer Dunzo niemand sonst Zugriff haben, um solche Änderungen vorzunehmen, und deshalb ist die Festlegung der Zugriffskontrolle wichtig.

Warum es wichtig ist, die richtige Zugriffskontrolle in einem Smart Contract festzulegen

Lassen Sie uns nun diesen Smart Contract bereitstellen und sehen, wie einfach es für einen Eindringling ist, die Werte in den Zustandsvariablen zu ändern.

Da sowohl die Funktionen setPrice als auch setPackageDelivered zugänglich sind, kann jeder Änderungen vornehmen, die zu finanziellen Verlusten für die Dunzo-Lieferung führen können.

Wenn Dunzo den ursprünglichen Preis des Artikels auf 5 ETH festgelegt hatte, kann der Kunde diesen Wert nun auf 3 ETH ändern. Da der Kunde natürlich auch auf die Funktion setPackageDelivered zugreifen und den booleschen Wert in „false“ ändern kann, kann es sein, dass er eine weitere Lieferung desselben Artikels erhält. In beiden Fällen riskiert Dunzo also, Geld zu verlieren, und merkt es möglicherweise erst, wenn es zu spät ist.

Nehmen wir zum Beispiel an, dass das gelieferte Produkt 5 ETH wert ist, wie unten dargestellt:

Nach der Bereitstellung sollte niemand außer Dunzo in der Lage sein, die Vertragsbedingungen zu ändern. Wenn wir jedoch in Remix die Adresse ändern und den Preis auf 3 zurücksetzen, ist dies möglich, da kein Schutz vorhanden ist.

Wir können sogar den setPackageDelivered-Status von true in false ändern. Auch wenn das Paket bereits beim Kunden zugestellt wurde.

Wie Sie sehen, ist es wichtig, zwischen dem Eigentümer und anderen Benutzern des Smart Contracts zu unterscheiden. Schauen wir uns also vier Korrekturen an, die die richtige Zugriffskontrolle für diesen Smart Contract festlegen und dadurch seine Sicherheit gewährleisten.

4 Möglichkeiten, Zugriffskontrollen für Ihren Smart Contract sicher einzurichten

Wie kann man also beim Verfassen intelligenter Verträge zwischen dem Eigentümer und anderen Benutzern unterscheiden?

Dies ist offensichtlich notwendig, da bei Nichtbeachtung ein finanzieller Verlust entstehen kann.

Methode Nr. 1: Verwenden Sie eine Require-Anweisung

Wie Sie im folgenden Code sehen können, wurde ein neuer Statusvariableneigentümer vom Typ „Adresse“ zusammen mit einer „require“-Anweisung hinzugefügt. Im Konstruktor speichert die Eigentümerstatusvariable die Adresse, die beim Bereitstellen des Vertrags verwendet wird. Wie Sie wissen, werden Konstruktoren in Smart Contracts nur einmal aufgerufen, sodass die Adresse nicht geändert werden kann.

Wenn Sie nun die Funktion „setPrice“ mit einem niedrigeren Wert und einer anderen Adresse aufrufen, wird die Transaktion in den Ausgangszustand zurückgesetzt, ähnlich wie die folgende Meldung:

Wie Sie sehen können, handelt es sich bei dem im Vertrag angegebenen Grund um die Fehlermeldung, die wir der „require“-Anweisung hinzugefügt haben. Allerdings kann niemand außer dem Vertragsinhaber – in diesem Fall Dunzo – die Verkaufsbedingungen ändern.

Methode Nr. 2: Verwenden Sie einen Funktionsmodifikator

So einfach es auch ist, eine „require“-Anweisung mit der richtigen Bedingung hinzuzufügen, ein Modifikator ist ein Codeblock, den Sie wiederholt verwenden können. Dies ist sicherlich viel sinnvoller, als für eine solche Prüfung zahlreiche „erforderliche“ Anweisungen zu schreiben.

Im zuvor freigegebenen Code ist nur die Funktion „setPrice“ durch eine „require“-Anweisung geschützt, für die Funktion „setPackageDelivered“ wurde hier jedoch nichts unternommen. Die Verwendung eines Modifikators sollte ausreichen, wie im folgenden Solidity-Code gezeigt:

Wenn Sie nun versuchen, auf die Funktionen „setPrice“ oder „setPackageDelivered“ zuzugreifen, erhalten Sie die gleiche Fehlermeldung wie zuvor, wie unten gezeigt:

Methode Nr. 3: Besitzbar

Für diesen Fix müssen Sie den von OpenZeppelin bereitgestellten Ownable-Smart-Vertrag verwenden. Zuerst müssen Sie den Ownable-Smart-Vertrag importieren und dann den onlyOwner-Modifikator zu den Funktionen hinzufügen, die Sie schützen möchten. Wie unten gezeigt, verfügen sowohl die Funktionen „setPrice“ als auch „setPackageDelivered“ über den folgenden Modifikator „onlyOwner“.

Da der dunzoDelivery-Smart-Vertrag nun einige der Funktionen in Ownable.sol nutzen wird, wird dem Vertragsnamen auch „is Ownable“ hinzugefügt.

Allerdings gibt es zwei weitere Funktionen, auf die man bei Verwendung des Ownable-Smart-Vertrags zugreifen kann: renounceOwnership und transferOwnership. Während in der Regel das Konto als Eigentümer gilt, das für die Bereitstellung des Vertrags verwendet wurde, kann dies mit diesen Funktionen geändert werden.

Neben der Adresse des Eigentümers und den anderen Vertragsdetails können Sie unten auch die Funktionen „renounceOwnership“ und „transferOwnership“ zur Verwendung sehen:

Wenn Sie versuchen, die setPrice-Funktion mit einer anderen Adresse aufzurufen, wird die Transaktion erwartungsgemäß nicht durchgeführt. Stattdessen wird der ursprüngliche Zustand aus dem unten angegebenen Grund wiederhergestellt:

Die Verwendung des Ownable-Smart-Vertrags ist sinnvoll, wenn Sie unter anderen Benutzern nur einen einzigen Eigentümer benötigen. Wenn Sie mehr Hierarchie wünschen, sollte der Smart Contract AccessControl.sol verwendet werden.

Methode Nr. 4: Zugriffskontrolle

Für diesen letzten Fix müssen Sie auf den AccessControl-Smart-Vertrag von Open Zeppelin zugreifen.

Zunächst müssen Sie den Hyperlink „Access Control“ zur Importanweisung hinzufügen und „is AccessControl“ zur Vertragsanweisung hinzufügen.

Wie bereits erwähnt, können Sie mit diesem Smart Contract eine Reihe von Rollen innerhalb einer Hierarchie hinzufügen, die Sie deklarieren müssen, wie in den ersten beiden Zeilen des unten gezeigten Smart Contracts:

In diesem Vertrag gibt es zwei Rollen, nämlich Dunzo und Kunde. Wenn Sie nun den Vertrag bereitstellen, müssen Sie diesen Adressen die oben genannten deklarierten Rollen zuweisen, um festzulegen, wer worauf zugreifen kann. Darüber hinaus wurden den Funktionen setPrice und setPackageDelivered zwei „require“-Anweisungen hinzugefügt.

Wie Sie sehen, kann nur das Konto, dem die Dunzo-Rolle zugewiesen wurde, die zum Zeitpunkt der Bereitstellung genannten Verkaufsbedingungen ändern, andere jedoch nicht. Allerdings können Sie mit AccessControl.sol eine Reihe von Rollen mit unterschiedlichen Zugriffsebenen auf Funktionen eines Smart Contracts zuweisen, während Ownable.sol nicht so tief in die Tiefe geht.

Ein Hinweis zu anderen Zugriffskontrollkorrekturen für Ethereum Smart Contracts

Dies sind jedoch nicht die einzigen verfügbaren Lösungen zur Implementierung der Zugriffskontrolle in Smart Contracts. RBAC.sol und WhitelistCrowdSale.sol waren in der Vergangenheit ebenfalls verfügbar und können, ähnlich wie AccessControl.sol und Ownable.sol, auch Rollen mit Adressen verknüpfen.

Wenn Sie also ein umfassendes Verständnis für die Entwicklung der Implementierung der Zugriffskontrolle erlangen möchten, lohnt es sich, auch den Code in diesen beiden Smart Contracts durchzugehen.

Auch hier veröffentlicht.

Das Leitbild für diesen Artikel wurde vomAI Image Generator von HackerNoon über die Eingabeaufforderung „Zugriff verweigert biometrischer Scan“ generiert.