Die Leute nutzen diesen Vertrag jeden Tag http://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol und es ist auch der Vertrag mit den meisten Ethereums im Moment.
Mit diesem Vertragsquellcode können Sie auch ein Multisig-Konto im offiziellen Ethereum Wallet erstellen.
Aber wenn ich dann auf die Seite https://etherscan.io/address/0xab7c74abc0c4d48d1bdad5dcb26153fc8780f83e#code gehe , haben wir all diese Warnungen , die diese niedrige Sicherheit angeben
Warnung: Der kompilierte Vertrag ist möglicherweise anfällig für ZeroFunctionSelector (sehr niedriger Schweregrad), DelegateCallReturnValue (niedriger Schweregrad), ECRecoverMalformedInput (mittlerer Schweregrad), SkipEmptyStringLiteral (niedriger Schweregrad), IdentityPrecompileReturnIgnored (niedriger Schweregrad), HighOrderByteCleanStorage (hoher Schweregrad). ), SendFailsForZeroEther (niedriger Schweregrad), DynamicAllocationInfiniteLoop (niedriger Schweregrad), CleanBytesHigherOrderBits (mittlerer/hoher Schweregrad) Solidity-Compilerfehler.
Wie sollte ich als Investor (und als Programmierer, der Solidity nicht vollständig gelernt hat) dies verwenden? Natürlich habe ich von dem Parity-Exploit gehört, der Hackern die Freiheit gab, einfach 30 Millionen USD zu nehmen.
Meine Frage: Muss ich mir Sorgen machen ? Und worauf muss ich achten und achten ?
AKTUALISIEREN:
Ich verstehe Sie, aber ich kann die grundlegende Solidität und ich kann keine "internen" Funktionen oder "Wächter" sehen, die nach ihrem Exploit durch Parität in Aktion gesetzt wurden.
Aber hier habe ich eine eingehendere Analyse des Solidity-Remix-Simulators, der Schwachstellen bei Wiedereintritt feststellt: https://imgur.com/a/d3x8J
UPDATE 2:
Sie sagten, eine höhere Compiler-Version sei besser, und alle Verträge, die diesen Code verwenden (von dem ich sagte, dass er in der Ethereum-Brieftasche verwendet wird), verwenden Version 0.3.2! 0.3.2! Das ist von 2016!
Das gesamte Ethereum-Ökosystem befindet sich in der Anfangsphase. Fehler sind zu erwarten, aber natürlich nicht zu tolerieren, wenn es um hohe Summen geht.
Grundsätzlich gibt es zwei Arten von Schwachstellen, die den Diebstahl von Geldern ermöglichen können:
Programmierfehler
Beispielsweise war die Re-Entrancy-Schwachstelle früher alltäglich. Die meisten DApp-Entwickler sind sich heute dessen bewusst und werden diesen Fehler nicht machen.
Heutzutage sind die meisten Fehler spezifisch für die Logik einer bestimmten Anwendung. Der einzige Weg, wie Sie sicher sein können, dass es keine gibt, ist eine formelle Überprüfung, eine umfassende Codeüberprüfung und/oder der Test von Zeit und Geld.
Compiler-Fehler
Dies sind Fehler, die den Entwicklern von Solidity-Compilern unterlaufen sind. Sie sind für DApp-Entwickler praktisch unmöglich zu erkennen oder etwas dagegen zu unternehmen.
Sobald ein Smart Contract mit einem Fehler kompiliert und auf der Blockchain bereitgestellt wurde, bleibt der Fehler bestehen. Die Vertragsbereitstellung ist endgültig.
Es ist wichtig zu beachten, dass nur weil ein Compiler einen Fehler hat, dies keineswegs bedeutet, dass alle Verträge, die mit diesem Compiler kompiliert wurden, einen Fehler haben. Compiler-Bugs wirken sich nur in seltenen Situationen negativ aus. (Sonst wären sie schon vor langer Zeit entdeckt worden, bevor die Compiler-Version mit dem Fehler veröffentlicht wurde)
Sie sollten all den Warnungen, die etherscan.io gibt, nicht zu viel Aufmerksamkeit schenken. Sie sehen sich einfach an, welche Compiler-Version verwendet wurde, und geben eine Liste aller bekannten Fehler für diese Compiler-Version. Sie führen nicht wirklich eine gründliche Analyse jedes Vertrags durch. Die Chancen stehen gut, dass der Vertrag, den Sie sich ansehen, nicht von diesen Fehlern betroffen war.
Es ist eine gute Idee, Solidity zumindest auf einer grundlegenden Ebene zu lernen und nur den Code zu lesen, um zu sehen, dass keine offensichtlichen Fehler gemacht wurden. Fehler wie Re-Entrancy-Schwachstellen sind ziemlich leicht zu erkennen. Außerdem sollten Sie nach logischen Fehlern in der Programmierung der spezifischen Anwendung suchen, die Sie sich ansehen.
Einige allgemeine Tipps:
Eine höhere Compiler-Version ist im Allgemeinen weniger riskant.
Verträge mit geprüftem Quellcode sind im Allgemeinen weniger riskant.
Kürzere Verträge sind im Allgemeinen weniger riskant.
Verträge, die schon lange bestehen, mit großen Geldbeträgen zu tun haben und nicht gehackt wurden, sind im Allgemeinen weniger riskant.
Leider gibt es keine Garantien für alle Verträge.
Ich hoffe das hilft etwas.
Dies ist eine gute Antwort von @Jesse Busman, aber wie Sie sehen können, gibt der Solidity-Compiler eine mögliche Wiedereintrittsschwachstelle an, dies geschieht jedoch nur durch statische Analyse, und der Compiler sucht nicht nach Modifikatoren. Hier ist eine anfällige Funktion für den Wiedereintritt, aber eine, die sicher ist:
function reEnterMe(uint256 etherAmt) onlyOwner {
if (balances[owner] >= etherAmt){
owner.send(etherAmt);
balances[owner] -= etherAmt;
}
}
Da der Kontrakt Ether sendet, BEVOR er von der Salden[Eigentümer]-Zuordnung abgezogen wird, kann diese Funktion erneut aufgerufen werden.
Der Modifikator onlyOwner verhindert jedoch, dass JEDER außer dem Eigentümer diesen Vertrag aufruft, oder er wird ausgelöst. Daher ist diese Funktion relativ sicher, denn wer möchte schon wieder in einen eigenen Vertrag einsteigen?
Jonathan Lindgren