Solidity kann als eine "höhere" Sprache als Serpent angesehen werden. Gibt es irgendwelche "Low-Level"-Funktionen in Serpent oder die in Serpent implementiert werden könnten, die mit Solidity entweder unmöglich oder nicht machbar sind?
Wenn dies der Fall ist, würde uns eine Reihenfolge von dem, was unmöglich ist, bis zu dem, was nicht machbar oder unwahrscheinlich ist, in Solidity implementiert zu werden, helfen, zu bestimmen, ob eines über dem anderen verwendet werden muss.
Ich glaube nicht, dass es eine "Beschränkung" für Solidity gibt, Funktionen/Zugriffe auf niedriger Ebene zu implementieren, wie z. B. die Arten von Dingen, die Serpent tun kann. Die beiden Sprachen können jedoch unterschiedliche Prioritäten haben. Serpent konzentriert sich wahrscheinlich auf Funktionen auf niedrigerer Ebene im Vergleich zur Flaggschiff-Hochsprache Solidity.
Ethereum-Hochsprachen, um nach Nähe direkt auf die EVM zugreifen zu können:
Serpent hat direkten Zugriff auf EVM-Opcodes (es ist eine Obermenge der LLL-Hochsprache) , aber es hat auch eine Reihe von High-Level-Funktionen. Der Nachteil von Serpent ist, dass der Compiler komplexer ist und daher theoretisch mehr Fehler enthalten könnte.
Es kann argumentiert werden, dass Solidity anfälliger für Probleme im Zusammenhang mit der Stapeltiefe ist:
Vitalik Buterin hat diesen Reddit-Kommentar geschrieben :
Solidity kompiliert alle Variablen in Werte auf dem Stack, und mit DUPN-Methoden in Ethereum können Sie jeweils nur den 2. bis 16. Wert vom Stack abrufen. Die tatsächliche Stack-Tiefe beträgt 1024. Serpent-Variablen werden in Speicherzugriffe kompiliert, sodass Sie dieses Problem in Serpent nicht haben; Um es solide zu umgehen, würde ich empfehlen, dass Sie versuchen, die Dinge mehr in Strukturen zu packen.
Als Flaggschiffsprache konzentriert sich Solidity auf andere Prioritäten als Serpent. Solidity hat sich weniger auf das Hinzufügen von Low-Level-Features zugunsten von High-Level-Features konzentriert, aber ich glaube nicht, dass es unmöglich ist, Solidity weitere Low-Level-Features hinzuzufügen. Tatsächlich gibt es in der Solidity-Entwicklungs-Roadmap eine Geschichte, in der Solidity Inline-ASM hinzugefügt wird, was den Zugriff auf die EVM auf niedrigerer Ebene ermöglichen würde.
Dies ist nicht gerade ein Vergleich der beiden Sprachen, aber relevant für jemanden, der eine der anderen überdenken möchte.
Ein Audit hat kritische Fehler in Serpent festgestellt, wobei die Prüfer das Serpent-Projekt als „niedrige Qualität“ und „fehlerhaft“ bezeichneten.
Vitalik, der Serpent schrieb, sagte dies in einem Tweet : „PSA: Ich betrachte Serpent jetzt als veraltete Technologie; nicht annähernd genug Sicherheitsschutz nach aktuellen Standards.“
Es sieht auch so aus, als würde Vitalik Serpent nicht weiter entwickeln, wobei sein Fokus auf Viper, das er ebenfalls getwittert hat, erst nach einem externen Audit fertig ist.
Der Zeppelin-Bericht legt nahe, dass Solidity heute die beste verfügbare Antwort ist, da mehr Entwickler daran arbeiten und es die Flaggschiffsprache ist. Allerdings müssen sie das gleiche Audit für Solidity noch durchführen.
Der Hauptunterschied ist eine Syntax. Serpent ist eher Python-ähnlich, während Solidity Javascript-CPP-ähnlich ist
Aber Solidity ist auch besser entwickelt und hat nette Funktionen als Vorlagen.
Im Internet finden Sie noch viele weitere Beispiele für Soliditätscodes.
eth
Hudson Jameson