> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Mempool
> Wie Transaktionen aufgenommen, gehalten, geordnet und verbreitet werden, bevor der Konsens sie in einem Block festschreibt.
Der Mempool steht zwischen einer signierten Transaktion und einem festgeschriebenen Block. Er entscheidet, was es wert ist, gehalten zu werden, in welcher Reihenfolge die Transaktionen eines Absenders infrage kommen, welche Peers von einer Transaktion erfahren und was verworfen wird, wenn die Nachfrage die Kapazität übersteigt.
Für ein Handelsnetzwerk ist das tragend und nicht nebensächlich. Order- und Stornoverkehr kommt schubweise, konzentriert sich auf wenige Absender und ist auf asymmetrische Weise latenzempfindlich: Eine Stornierung, die zu spät kommt, ist schlimmer als eine Order, die zu spät kommt. Die folgenden Strukturen existieren, weil eine einzelne FIFO-Warteschlange nichts davon gut bewältigt.
Der Weg hinein
Signierte Transaktion
ValidierungSignatur · Format · Kontozustand · kann der Absender zahlen
Verworfen, mit Begründungnicht still – der Einreicher erfährt, warum
Transaktionsspeicher
Verteilung an Peers
Batch-Bildung, dann Konsens
Die Validierung ist billig und lokal – die teuren Ressourcen weiter hinten gehen nur an Transaktionen, die wirklich ausführbar sind.
abgelehnt
angenommen
Eine Transaktion wird validiert, bevor sie überhaupt gespeichert wird. Die Validierung ist billig und lokal – Signatur, Format, Kontozustand und ob der Absender bezahlen kann, was er verlangt – und sie existiert, damit die teuren Ressourcen weiter hinten nur für Transaktionen aufgewendet werden, die tatsächlich ausführbar wären. Eine Ablehnung an dieser Stelle gibt dem Einreicher eine Begründung zurück, statt still zu verschwinden.
Wie Transaktionen gehalten werden
Angenommene Transaktionen liegen nicht in einer flachen Warteschlange. Der Speicher führt mehrere Sichten über dieselbe Menge, von denen jede eine andere Frage beantwortet.
Eine Menge angenommener Transaktionenfünf Sichten, keine fünf Queues
Reihenfolge je KontoWas ist für diesen Absender die nächste?
PrioritätsindexWas wird dem Konsens über alle Absender zuerst angeboten?
AblaufindexWas hat seine Frist überschritten?
Timeline-IndexWovon hat dieser Peer noch nichts gehört?
ParkplatzWas ist wohlgeformt, aber noch nicht dran?
Auf dem Parkplatz wird ein Integrationsfehler sichtbar: Eine Transaktion, die gültig, aber für ihren Absender noch nicht die nächste ist, wird geparkt statt abgelehnt – sie kommt infrage, sobald sich die Lücke davor schließt.
| Sicht | Frage, die sie beantwortet |
| ------------------------ | ------------------------------------------------------------------------- |
| **Reihenfolge je Konto** | Welche Transaktion ist für diesen Absender die nächste? |
| **Prioritätsindex** | Was sollte über alle Absender hinweg dem Konsens zuerst angeboten werden? |
| **Ablaufindex** | Was hat seine Frist überschritten und sollte entfernt werden? |
| **Timeline-Index** | Wovon hat dieser Peer noch nichts gehört? |
| **Parkplatz** | Was ist wohlgeformt, kommt aber noch nicht infrage? |
Der **Parkplatz** verdient die meiste Aufmerksamkeit, weil dort eine ganze Klasse von Integrationsfehlern sichtbar wird. Eine Transaktion kann vollkommen gültig sein und trotzdem nicht als Nächste für ihren Absender an der Reihe sein – meist, weil eine frühere Transaktion desselben Kontos nicht angekommen oder nicht festgeschrieben ist. Eine solche Transaktion wird geparkt statt abgelehnt: Sie bleibt verfügbar und kommt in dem Moment infrage, in dem sich die Lücke vor ihr schließt. Ein Client, der außer der Reihe einreicht, erlebt also eine Verzögerung und keinen Fehlschlag – aber ein Client, der die Lücke nie füllt, lässt Arbeit geparkt liegen, bis sie verfällt.
Der **Timeline-Index** macht die Verbreitung an Peers inkrementell. Für jeden Peer wird festgehalten, bis wohin auf der Timeline er bereits bedient wurde, sodass eine Verteilung genau das sendet, was diesem Peer fehlt, statt den ganzen Pool erneut zu schicken. Die Timeline ist in Buckets aufgeteilt statt einspurig, was verhindert, dass ein einzelner besonders aktiver Absender jeden Sendeslot belegt.
Verbreitung und Fairness
Nicht jede Node erfährt unabhängig von den anderen von einer Transaktion. Eine Node, die eine Transaktion annimmt, verteilt sie an ihre Peers, und die Peers werden nicht gleich behandelt – vorgelagerte Peers werden bevorzugt, damit eine Transaktion sich auf die Validatoren zubewegt, die auf sie reagieren können, statt gleichmäßig ins Netzwerk zu diffundieren.
Fairness wird über die jüngste Historie verfolgt und nicht pro Nachricht erzwungen. Der Mempool führt eine gleitende Aufzeichnung darüber, welche Absender und welche Verkehrsarten zuletzt Kapazität verbraucht haben, und formt damit, was als Nächstes bedient wird. Das ist der Mechanismus, der verhindert, dass der Order-und-Storno-Sturm eines einzelnen Kontos den Rest des Netzwerks verdrängt – ohne ein hartes Rate-Limit je Konto, das legitimes Market Making bestrafen würde.
Übergabe an den Konsens
Der Konsens holt sich Transaktionen nicht einzeln aus dem Mempool. Transaktionen werden zu **Batches** gebündelt, Batches werden im Hintergrund an die Validatoren verbreitet, und jeder Batch wird quittiert, bis sein Urheber nachweisen kann, dass ein ausreichender Teil des Netzwerks ihn vorhält. Erst dann kann ein Blockvorschlag ihn referenzieren.
Die Folge: Ein Blockvorschlag führt Batch-Digests statt Transaktionsrümpfen mit, sodass die Größe der Konsensnachrichten bei steigendem Durchsatz konstant bleibt – und ein festgeschriebener Block ist immer erneut ausführbar, weil die Daten dahinter als verfügbar nachgewiesen wurden, bevor sie referenziert wurden. Wie dieser Nachweis gebildet und genutzt wird, steht unter [IntentionBFT](/de/protocol/architecture/intention-bft).
Auch deshalb ist die Aufnahme in den Mempool nicht dasselbe wie die Aufnahme in einen Block. Eine Transaktion, die angenommen, gespeichert und verteilt wurde, ist in die Warteschlange eingetreten; einen Platz in der Reihenfolge hat sie damit nicht. Über das Schicksal einer Transaktion ist nichts entschieden, bis der Konsens den Block festschreibt, der sie enthält.
Was das für einen Client bedeutet
* **Eine Ablehnung beim Einreichen ist informativ.** Sie erfolgte, bevor die Transaktion gespeichert wurde, und die Begründung beschreibt etwas, das der Client beheben kann.
* **Schweigen ist keine Ablehnung.** Eine Transaktion kann hinter einer Lücke geparkt sein, die der Client selbst erzeugt hat. Verfolgen Sie, was eingereicht und was festgeschrieben wurde, statt eine fehlende Quittung als Verlust zu deuten.
* **Die Reihenfolge innerhalb eines Kontos zählt, die Reihenfolge über Konten hinweg nicht.** Zwei Transaktionen desselben Absenders haben eine definierte Abfolge. Zwei Transaktionen verschiedener Absender ordnet der Konsens, nicht wer zuerst eingereicht hat.
* **Stornierungen sind im Mempool nicht privilegiert.** Der Vorrang von Stornierungen ist eine Eigenschaft der [Kernel-Ausführung](/de/protocol/architecture/kernel), wo Stornierungen im selben Block vor aggressiven Platzierungen laufen – und keine Eigenschaft der Warteschlange.