Gibt RLP eine Ganzzahlcodierung an?

Die RLP-Spezifikation sagt Folgendes über ganze Zahlen:

Der einzige Zweck von RLP besteht darin, die Struktur zu codieren; die Kodierung spezifischer atomarer Datentypen (z. B. Strings, Ints, Floats) wird den Protokollen höherer Ordnung überlassen; In Ethereum müssen Ganzzahlen in Big-Endian-Binärform ohne führende Nullen dargestellt werden (wodurch der Ganzzahlwert Null dem leeren Byte-Array entspricht).

Wenn „in Ethereum“ steht, bedeutet dies eigentlich nur im ETH-Subprotokoll oder bedeutet dies im Hauptwerk „Ethereum“ und speziell im RLP-Protokoll? Wenn letzteres der Fall ist, scheint sich dieser Absatz zu widersprechen. Auf der einen Seite heißt es, dass RLP die Codierung höheren Protokollen überlässt, aber auf der anderen Seite, dass RLP Big-Endian-Integer verlangt, bei denen alle führenden Nullen übersprungen werden.

Wo soll diese Kodierung dann implementiert werden? Oder sollte es im RLP-Protokoll einen bestimmten Typ „EthereumInteger“ geben, der sich von „Integer“ unterscheidet?

Vielleicht wäre eine bessere Frage, an wen sollte diese Art von Frage am besten gerichtet werden und wo?

Die folgende Antwort ist richtig, wenn sie alle Kommentare enthält.

Antworten (1)

RLP befasst sich nur mit Strukturen, die aus Bytes (Binärdaten) bestehen. Es spielt keine Rolle, ob diese Bytes Zeichenfolgen, Ganzzahlen, große Ganzzahlen, Gleitkommazahlen oder was auch immer darstellen. Dies ist in dem Satz vor dem, den Sie zitiert haben,

Der Zweck von RLP (Recursive Length Prefix) besteht darin, willkürlich verschachtelte Arrays von Binärdaten ...

Zu deiner Frage:

...aber auf der anderen Seite sagt RLP, dass Big-Endian-Ganzzahlen verlangt werden, bei denen alle führenden Nullen übersprungen werden.

Nein, das sagt es nicht. Es besagt, dass Integer in Ethereum als Big Endian ohne führende Null-Bytes dargestellt werden.

RLP ist nicht spezifisch für Ethereum (obwohl es für Ethereum AFAIK entwickelt wurde). Der Punkt ist, dass Ethereum eines der in diesem Satz erwähnten „Protokolle höherer Ordnung“ ist. Also macht alles Sinn:

  • RLP codiert beliebige Binärdaten und kümmert sich nicht darum, was sie in einem übergeordneten Protokoll darstellen;
  • [impliziert "Als Beispiel für ein solches Protokoll höherer Ordnung ..."] Ethereum-Ganzzahlen müssen in Big-Endian-Binärform ohne führende Nullen dargestellt werden.

Zugegebenermaßen könnte der Ethereum-Teil weggelassen werden und die Dinge könnten klarer sein. Ich denke, der Autor wollte der Konkretheit halber nur ein Beispiel für ein solches Protokoll höherer Ordnung geben.

Danke dafür, aber ich weiß noch nicht, ob das stimmt. Beispielsweise werden Ethereum-Ganzzahlen in Methodenaufrufen nicht auf diese Weise codiert. Dies sieht eher so aus, als würde es versuchen zu sagen, dass die Ethereum-spezifische Implementierung von RLP so codiert werden muss, nicht die gesamte Arbeit von Ethereum. Und wenn Sie andere Protokolle sagen, meinen Sie damit nur ETH oder devp2p oder shh usw.?
"Zum Beispiel werden Ethereum-Ganzzahlen in Methodenaufrufen nicht auf diese Weise codiert." - Dies sind keine ganzen Zahlen, sondern ABI-Byte-Strings. Ein Smart Contract kann entscheiden, sie als ganze Zahlen oder als etwas anderes zu interpretieren. Dies ist nicht RLP-bezogen. RLP ist RLP völlig unabhängig von Etherem. Sehen Sie sich den Beispielcode im Artikel an; es gibt nichts Ethereum-spezifisches darin.
Okay danke dafür. Ich versuche nur zu lernen. Können Sie darauf hinweisen, wo angegeben ist, dass Ethereum-Ganzzahlen als Big-Endian-No-Leading-Zero-Bytes dargestellt werden? Auch in der RLP-Protokollspezifikation ist die "Länge der Zeichenfolge in Binärform" welcher Datentyp, wenn nicht Big-Endian-Ganzzahl ohne führende Null? ZB: dieser Satz in der RLP-Spezifikation: "gefolgt von der Länge der Nutzlast".
Lernen ist gut :-) Das Ethereum Yellow Paper ist die kanonische Referenz. Für die spezifische Ethereum-Implementierung von RLP siehe Anhang B. Am Ende dieses Anhangs können Sie eine Aussage sehen, dass (in Ethereum-Clients) „wenn ein erwartetes Fragment als Skalar dekodiert wird und führende Nullen in der Bytesequenz gefunden werden“ es ist als ungültig anzusehen. Für Big-Endian siehe den ersten Satz von Anhang H. Nur bei der RLP-Codierung von Ganzzahlen in Ethereum müssen führende Null-Bytes weggelassen werden. Es ist per se kein allgemeines Merkmal von Ethereum.
Danke nochmal. Das Problem, das ich habe, ist, ob ich einen Typ "Ethereum Integer" implementieren soll, der seine eigene Byte-Darstellung beibehält, oder ob ich diese Details in einer Ethereum-spezifischen Version von RLP implementieren soll. (Ich entwickle einen Light-Client) Obwohl ich mir diese Yellow Paper-Anhänge noch nicht angesehen habe, sehe ich noch nichts, was darauf hindeutet, dass etwas anderes als Ethereum RLP dies erfordert. Auch die Wiki-Dokumentation für RLP scheint Ihrem Zitat aus Anhang B zu widersprechen. Beachten Sie, dass die Codierung für die Länge der Zeichenfolge eine Ganzzahl ist und für RLP spezifisch ist.
Ich sehe es jetzt eine Big-Endian-Ganzzahl ist gleich der Länge des Eingabe-Byte-Arrays"
Wenn Sie die Spezifikation in Anhang B einhalten, sind Sie für einen Ethereum-Client in Ordnung. RLP ist allgemeiner, aber Ethereum fügt diese Einschränkung über führende Nullen bei ganzzahligen Mengen hinzu, was meiner Meinung nach eine Ethereum-spezifische Implementierung erfordert (nicht in RLP selbst - RLP kennt nichts außer Bytes und Längen/Strukturen - sondern in der Verarbeitung von Eingaben zu und Ausgabe von RLP). Das YP ist für Ethereum-Kunden kanonisch.
Okay jetzt habe ich es. In der Tat, wenn der Anhang B im Yellow Paper die RLP-Spezifikation ist, dann sagen die anderen Protokolle in Ethereum demnach nichts über die Darstellung von Ganzzahlen mit minimaler Länge. Es ist nur RLP, und es ist Teil der RLP-Spezifikation. Danke, dass du mir geholfen hast, die Antwort zu finden!
Ich denke, wir haben uns angeglichen: Anhang B ist die RLP-Spezifikation von Ethereum , und ich stimme Ihren anderen Aussagen zu. Wie auch immer, es war interessant, dies noch einmal zu besuchen. Viel Glück mit dem Light-Client!
Danke schön. Ich bin mir sicher, dass wir uns wieder kreuzen werden. Die Zukunft ist Blockchain.
Gibt RLP eine Ganzzahlcodierung an?
AntwortenHierDatenschutz-Bestimmungen1y, 0v