Ist die Ethereum-Blockchain eine Liste/Kette von Transaktionen oder eine Liste von Verträgen?

Ethereum-Neuling hier mit einigen allgemeinen Programmierkenntnissen, einschließlich grundlegender Solidity. Unten ist mein aktuelles mentales Bild davon, wie Ehtereum funktioniert (bitte korrigieren Sie mich, wenn ich falsch liege).

Ein Vertrag ist eine Klasse (im OOP-Begriff), die eine Reihe von Funktionen enthält, die von jedem aufgerufen werden können, sobald sie in der Blockchain bereitgestellt werden. Jede Funktion kann Ether-Transaktionen enthalten oder nicht.

Wenn ich also Ether als Bitcoin betrachte, dann sollte die Ethereum-Blockchain eine Liste von Blöcken enthalten, wobei jeder Block eine Reihe von Ether-Transaktionen enthält, einschließlich der Belohnung für den Miner dieses Blocks.

Aber manchmal hatte ich auch den Eindruck, dass die Ethereum-Blockchain eigentlich eine Liste von Verträgen ist, da jeder Vertrag eine „Adresse“ hat und nach seiner Bereitstellung unveränderlich ist.

Welcher ist wahr (oder keiner von beiden)?

Antworten (1)

Die Ethereum-Blockchain sollte eine Liste von Blöcken enthalten, wobei jeder Block eine Reihe von Ether-Transaktionen enthält, einschließlich der Belohnung für den Miner dieses Blocks.

Jeder Block ist eine wohlgeordnete Liste von Transaktionen, die vom Netzwerk akzeptiert wurden. Die Blöcke selbst sind wohlgeordnet, also ist die Blockchain ein wohlgeordneter Satz von Transaktionen. Transaktionen werden zugelassen oder verweigert, je nachdem, ob sie dem Protokoll folgen (korrekte Unterschrift, genügend Geld, akzeptabel für den empfangenden Vertrag usw.).

Ich hatte auch den Eindruck, dass die Ethereum-Blockchain eigentlich eine Liste von Verträgen ist, da jeder Vertrag eine „Adresse“ hat und nach seiner Bereitstellung unveränderlich ist.

Zusätzlich zu den Konten und und fromenthält das Ethereum-Protokoll die Höhe von und die (eine Art Priorität) und, was wichtig ist .toamountgasgasPricedata

Eine speziell gestaltete Transaktion, die an address( 0) gesendet wird, kann kompiliert bytecodefür einen Smart Contract im dataFeld enthalten. Wenn diese Transaktion akzeptabel ist, wird dem Vertrag eine Adresse zugewiesen. Solche Vertragsadressen sind praktisch nicht von Wallet-Adressen zu unterscheiden. Diese Bereitstellungstransaktionen machen die „Tatsache“ des bereitgestellten Vertrags für alle Beobachter sichtbar.

Verträge haben benannte Funktionen (z. B. Einzahlung, Auszahlung, Überweisung) und Adressen im gleichen Format wie externe Konten (Wallets). So kann man eine Transaktion unterzeichnen und an einen Vertrag statt an eine andere Brieftasche adressieren. Das dataFeld enthält normalerweise zusätzliche Informationen wie die aufzurufende Funktion und Argumente, die übergeben werden sollen. Verträge haben keine andere Wahl, als die eingehenden Transaktionen und Nachrichten von anderen Verträgen zu verarbeiten.

Ein Vertrag ist eine Klasse (im OOP-Begriff), die eine Reihe von Funktionen enthält, die von jedem aufgerufen werden können, sobald sie in der Blockchain bereitgestellt werden. Jede Funktion kann Ether-Transaktionen enthalten oder nicht.

Verträge sind praktisch nicht von Brieftaschen zu unterscheiden, aber sie haben einen Code anstelle von Inhabern privater Schlüssel. Sie haben internen Speicherplatz, also sind sie zustandsbehaftet. Sie haben Funktionen, die den Status aktualisieren oder melden können.

Es gibt Muster, die OOP sehr ähneln, aber das ist größtenteils eine Frage des Stils. Im Grunde ähneln sie eher zustandsbehafteten Anwendungsnetzwerkprotokollen. Einmal bereitgestellt, können sie nicht geändert werden und ihr interner Status (der das offensichtliche Ergebnis des Codes und aller Transaktionen ist, die an den Vertrag gesendet wurden) ist unveränderlich.

Sie werden erhebliche Diskussionen über erweiterbare Vertragsmuster finden, die meiner Meinung nach die Fakten für Neulinge verschleiern. Ein Vertrag kann nach der Veröffentlichung nicht mehr geändert werden, aber die Erstversion kann absichtlich ein modulares und aktualisierbares Design enthalten. Zum Beispiel das Delegieren eines Prozesses an einen anderen Vertrag und eine Art Verfahren, um die Verantwortung von Zeit zu Zeit neu zuzuweisen.

Der Code auf Maschinenebene wird auf der Protokollschicht definiert. Entwickler verwenden im Allgemeinen eine höhere Sprache wie Solidity, um die Verträge in menschenlesbarer Form zu schreiben und dann den Quellcode in Bytecode für die Ethereum Virtual Machine zu kompilieren.

Ich hoffe es hilft.

Danke! Es ist viel zu verdauen. Ist es richtig zu sagen: Ein Vertrag ist eine Transaktion, ein Vertrag ist auch ein Konto (Wallet)? Wenn ja, dann ist ein Konto auch eine Transaktion oder umgekehrt, oder sollte ich diese Art des Nachdenkens über Beziehungen zwischen Objekten im Ethereum-Universum aufgeben?
Ein Vertrag ist ein Maschinencode mit einer Adresse, die über eine spezielle Transaktion bereitgestellt wird. Anstelle von „Alice sendet Bob 5 BTC“, „Alice stellt den Code mit Anweisungen bereit, 0x660....die zum Vertrag an der Adresse führen 0x123...“, sendet Bob eine Transaktion, um 0x123...etwas zu bewirken.
„Bob sendet eine Transaktion an 0x123...“ ruft Bob also im Grunde genommen einige Funktionen für den bereitgestellten Vertrag auf?
Nah genug für Gespräche. ;-)