Warum gibt es auf Solana so viele Prop-AMMs, während sie auf EVM noch fehlen?

Originaltitel: Must-Watch dApps After Monad Mainnet Launch

Originalautor: Optimus, Gründer von Waterloo Blockchain

Originalübersetzung: Dingdang, Odaily

Prop AMMs haben schnell 40% des gesamten Handelsvolumens auf Solana eingenommen. Warum sind sie noch nicht im EVM-Ökosystem aufgetaucht?

Proprietäre Automated Market Maker (Proprietary AMMs, kurz Prop AMMs) werden rasch zur dominierenden Kraft im Solana DeFi-Ökosystem und machen mittlerweile über 40% des Handelsvolumens der wichtigsten Handelspaare aus. Diese von professionellen Market Makern betriebenen spezialisierten Liquiditätsplätze bieten tiefe Liquidität und wettbewerbsfähigere Preise, was vor allem daran liegt, dass sie das Risiko für Market Maker, durch „veraltete Quotes“ (stale quotes) ausgenutzt und durch Front-Running arbitrageiert zu werden, deutlich reduzieren.

Bildquelle: dune.com

Ihr Erfolg ist jedoch nahezu ausschließlich auf Solana beschränkt. Selbst auf schnellen und kostengünstigen Layer-2-Netzwerken wie Base oder Optimism sind Prop AMMs im EVM-Ökosystem kaum zu finden. Warum konnten sie sich im EVM nicht durchsetzen?

Dieser Artikel untersucht hauptsächlich drei Fragen: Was ist ein Prop AMM, welchen technischen und wirtschaftlichen Hürden begegnen sie auf EVM-Chains und welche vielversprechenden neuen Architekturen könnten sie letztlich an die Spitze von EVM DeFi bringen?

Was ist ein Prop AMM?

Ein Prop AMM ist ein Automated Market Maker, bei dem ein einzelner professioneller Market Maker Liquidität und Preisgestaltung aktiv verwaltet, anstatt wie bei traditionellen AMMs, bei denen die breite Masse passiv Kapital bereitstellt.

Traditionelle AMMs (wie Uniswap v2) verwenden in der Regel die Formel x * y = k zur Preisbestimmung, wobei x und y die Mengen der beiden Vermögenswerte im Pool darstellen und k eine Konstante ist. Bei Prop AMMs hingegen ist die Preisformel nicht fest, sondern wird hochfrequent aktualisiert (meist mehrmals pro Sekunde). Da die internen Mechanismen der meisten Prop AMMs eine „Blackbox“ sind, ist der genaue Algorithmus unbekannt. Der Prop AMM Smart Contract von Obric auf der Sui-Chain ist jedoch öffentlich (Dank an @markoggwp für den Hinweis), wobei die Invariante k von den internen Variablen mult_x, mult_y und concentration abhängt. Die folgende Abbildung zeigt, wie Market Maker diese Variablen kontinuierlich aktualisieren.

Es sei klargestellt: Die Formel auf der linken Seite der Obric-Preiskurve ist komplexer als einfach x*y, aber der Schlüssel zum Verständnis von Prop AMMs ist – sie entspricht immer einer variablen Invariante k, und der Market Maker aktualisiert dieses k ständig, um die Preiskurve anzupassen.

Wiederholung: Wie bestimmen AMMs den Preis?

In diesem Artikel werden wir häufig auf das Konzept der „Preiskurve“ zurückkommen. Die Preiskurve bestimmt, welchen Preis Nutzer beim Handel mit einem AMM zahlen müssen, und ist der Teil, den Market Maker bei Prop AMMs ständig aktualisieren. Um dies besser zu verstehen, lohnt sich ein Rückblick auf die Preisfindung bei traditionellen AMMs.

Am Beispiel des WETH-USDC-Pools auf Uniswap v2 (ohne Gebühren): Der Preis wird passiv durch die Formel x * y = k bestimmt. Angenommen, der Pool enthält 100 WETH und 400.000 USDC, dann ist der Punkt auf der Kurve x = 100, y = 400.000, was einem Anfangspreis von 400.000 / 100 = 4.000 USDC/WETH entspricht. Daraus ergibt sich die Konstante k = 100 * 400.000 = 40.000.000.

Möchte ein Trader 1 WETH kaufen, muss er USDC in den Pool einzahlen, sodass der WETH-Bestand auf 99 sinkt. Um das konstante Produkt k zu erhalten, muss der neue Punkt (x, y) weiterhin auf der Kurve liegen, daher muss y zu 40.000.000 / 99 ≈ 404.040,40 werden. Das heißt, der Trader zahlt für 1 WETH etwa 4.040,40 USDC, etwas mehr als der ursprüngliche Preis. Dieses Phänomen nennt man „Slippage“. Deshalb spricht man bei x*y=k von einer „Preiskurve“: Jeder handelbare Preis muss auf dieser Kurve liegen.

Warum wählen Market Maker AMM-Designs statt zentralisierter Orderbücher (CLOB)?

Warum wollen Market Maker AMM-Designs nutzen? Stellen Sie sich vor, Sie sind ein Market Maker, der auf einem On-Chain Central Limit Order Book (CLOB) quotiert. Um Ihre Quotes zu aktualisieren, müssen Sie Tausende von Limit Orders stornieren und ersetzen. Bei N Orders ist das ein O(N)-Vorgang – on-chain langsam und teuer.

Was aber, wenn Sie alle Quotes durch eine mathematische Kurve darstellen könnten? Dann müssten Sie nur wenige Parameter dieser Kurve aktualisieren, was den O(N)-Vorgang auf O(1) reduziert.

Um anschaulich zu zeigen, wie „Preiskurven“ unterschiedlichen effektiven Preisbereichen entsprechen, kann man SolFi von Ellipsis Labs als Beispiel nehmen – ein Prop AMM auf Solana. Obwohl die genaue Preiskurve unbekannt ist, hat Ghostlabs eine Grafik erstellt, die für einen bestimmten Solana-Slot (Blockzeitraum) die effektiven Preise beim Tausch verschiedener Mengen SOL gegen USDC zeigt. Jede Linie steht für einen anderen WSOL/USDC-Pool und zeigt, dass mehrere Preisstufen gleichzeitig existieren können. Wenn Market Maker die Preiskurve aktualisieren, ändert sich diese Preisdarstellung von Slot zu Slot.

Bildquelle: github

Der entscheidende Punkt ist hier: Durch das Aktualisieren weniger Preiskurvenparameter kann der Market Maker jederzeit die effektive Preisverteilung ändern, ohne N Orders einzeln anpassen zu müssen. Das ist der Kernnutzen von Prop AMMs – sie ermöglichen Market Makern, mit höherer Kapital- und Recheneffizienz dynamische und tiefe Liquidität bereitzustellen.

Warum ist Solanas Architektur ideal für Prop AMMs?

Prop AMMs sind „aktiv gemanagte“ Systeme, was zwei Schlüsselfaktoren erfordert:

1. Günstige Updates

2. Priorisierte Ausführung

Auf Solana gehen diese beiden Hand in Hand: Günstige Updates bedeuten meist auch, dass Updates mit Ausführungsvorrang versehen werden.

Warum brauchen Market Maker beides? Erstens: Sie aktualisieren die Preiskurve fortlaufend entsprechend Bestandsänderungen oder Indexpreisbewegungen (z.B. CEX-Preise) mit Blockchain-Geschwindigkeit. Auf einer Hochfrequenz-Chain wie Solana ist das bei hohen Update-Kosten kaum möglich.

Zweitens: Wenn Market Maker ihre Updates nicht an den Anfang des Blocks bringen können, werden ihre alten Quotes von Arbitrageuren „abgegriffen“, was zu sicheren Verlusten führt. Fehlen diese beiden Eigenschaften, können Market Maker nicht effizient agieren und Nutzer erhalten schlechtere Preise.

Am Beispiel des Prop AMM HumidiFi auf Solana: Laut @SliceAnalytics aktualisiert dieser Market Maker seine Quotes bis zu 74 Mal pro Sekunde.

Spieler aus dem EVM-Ökosystem fragen sich vielleicht: „Ein Solana-Slot dauert etwa 400ms, wie kann ein Prop AMM innerhalb eines Slots mehrfach Preise aktualisieren?“

Die Antwort liegt in Solanas kontinuierlicher Architektur, die sich grundlegend vom diskreten Blockmodell des EVM unterscheidet.

· EVM: Transaktionen werden in der Regel nach der vollständigen Blockvorschlag- und Bestätigungsphase sequentiell ausgeführt. Updates, die zwischendurch gesendet werden, werden erst im nächsten Block wirksam.

· Solana: Der Leader-Validator wartet nicht auf einen vollständigen Block, sondern zerlegt Transaktionen in kleine Datenpakete („shreds“), die kontinuierlich im Netzwerk verbreitet werden. Innerhalb eines Slots kann es mehrere Swaps geben, wobei shred #1 das Preisupdate für swap #1 beeinflusst, shred #2 das für swap #2 usw.

Hinweis: Flashblocks sind ähnlich wie Solanas shreds. Laut Anza Labs' @Ashwinningg auf der CBER-Konferenz liegt das Limit bei 32.000 shreds pro 400ms-Slot, also 80 shreds pro Millisekunde. Ob 200ms Flashblocks für Market Maker schnell genug sind, bleibt im Vergleich zu Solanas kontinuierlicher Architektur offen.

Warum sind Updates auf Solana so günstig? Und wie führt das zu priorisierter Ausführung?

Erstens: Obwohl die Implementierung von Prop AMMs auf Solana eine Blackbox ist, gibt es Bibliotheken wie Pinocchio, die Solana-Programme für Compute Units (CU) optimieren. Der Helius-Blog beschreibt, wie der Verbrauch von etwa 4000 CU auf etwa 100 CU gesenkt werden kann.

Bildquelle: github

Zweitens: Auf höherer Ebene sortiert Solana Transaktionen nach dem höchsten Fee/Compute Units-Verhältnis (Compute Units sind vergleichbar mit Gas im EVM), ähnlich wie im EVM.

· Mit Jito: Formel ist Jito Tip / Compute Units

· Ohne: Priority = (Priority Fee + Base Fee) / (1 + CU-Limit + Signature CU + Write Lock CU)

Vergleicht man die Compute Units von Prop AMM-Updates mit Jupiter Swaps, sieht man, dass Updates extrem günstig sind – das Verhältnis beträgt 1:1000.

Prop AMM Update: Einfaches Kurvenupdate ist extrem günstig. Wintermute-Updates benötigen nur 109 CU, Gesamtkosten nur 0.000007506 SOL

Jupiter Swap: Ein Swap über Jupiter-Routing kann ~100.000 CU verbrauchen, Gesamtkosten 0.000005 SOL

Aufgrund dieses enormen Unterschieds müssen Market Maker für Update-Transaktionen nur minimale Gebühren zahlen, um ein viel höheres Fee/CU-Verhältnis als bei Swaps zu erzielen, was garantiert, dass Updates am Blockanfang ausgeführt werden und sie vor Arbitrage schützen.

Warum sind Prop AMMs noch nicht im EVM angekommen?

Angenommen, das Update eines Prop AMMs beinhaltet das Schreiben von Variablen, die die Preiskurve des Handelspaars bestimmen. Obwohl der Prop AMM-Code auf Solana eine „Blackbox“ ist, wollen Market Maker ihre Strategien geheim halten. Wir können jedoch anhand des Prop AMM von Obric auf Sui nachvollziehen: Die entscheidenden Variablen für Quotes werden über eine Update-Funktion in den Smart Contract geschrieben.

Dank an @markoggwp für den Hinweis!

Mit dieser Annahme erkennen wir, dass die EVM-Architektur erhebliche Hürden aufweist, die das Solana-Prop-AMM-Modell im EVM unmöglich machen.

Zur Erinnerung: Auf OP-Stack Layer-2-Blockchains (wie Base und Unichain) werden Transaktionen nach der höchsten Gas-Priority Fee sortiert (ähnlich wie Solana nach Fee/CU sortiert).

Im EVM ist das Schreiben (SSTORE) extrem teuer. Im Vergleich zu Solana-Updates kostet das Schreiben eines Werts mit dem SSTORE-Opcode im EVM enorm viel:

· SSTORE (0 → nicht 0): ~22.100 Gas

· SSTORE (nicht 0 → nicht 0): ~5.000 Gas

· Typischer AMM Swap: ~200.000–300.000 Gas

Hinweis: Gas im EVM ist vergleichbar mit Compute Units (CU) auf Solana. Die oben genannten SSTORE-Gaswerte gehen von einem einzelnen Schreibvorgang pro Transaktion aus (Cold Write), was realistisch ist, da Updates meist nicht mehrfach pro Transaktion erfolgen.

Updates sind zwar immer noch günstiger als Swaps, aber das Gas-Verhältnis beträgt nur etwa 10x (Updates können mehrere SSTOREs beinhalten), während es auf Solana etwa 1000x ist.

Daraus ergeben sich zwei Schlussfolgerungen, die das Solana-Prop-AMM-Modell im EVM riskanter machen:

1. Hoher Gasverbrauch erschwert die Priorisierung von Updates, da niedrige Priority Fees kein hohes Fee/Gas-Verhältnis ermöglichen. Um sicherzustellen, dass Updates nicht überholt werden und am Blockanfang stehen, sind höhere Priority Fees nötig, was die Kosten erhöht.

2. Höheres Arbitragerisiko im EVM, da das Verhältnis von Update-Gas zu Swap-Gas nur 1:10 beträgt (auf Solana 1:1000). Arbitrageure müssen ihre Priority Fee nur um das 10-fache erhöhen, um Market Maker-Updates zu überholen, auf Solana wären es 1000-fach. Bei diesem niedrigen Verhältnis ist es für Arbitrageure günstiger, Preisupdates zu front-runnen und von veralteten Quotes zu profitieren.

Einige Innovationen (wie EIP-1153s TSTORE für temporären Speicher) bieten etwa 100 Gas pro Schreibvorgang, aber dieser Speicher ist nur innerhalb einer Transaktion gültig und kann nicht für persistente Preisupdates für nachfolgende Swaps (z.B. während eines gesamten Blocks) genutzt werden.

Wie kann man Prop AMMs ins EVM bringen?

Vorab: Warum sollte man das tun? Nutzer wollen immer bessere Quotes, also günstigere Trades. Prop AMMs auf Ethereum und Layer 2 können Nutzern wettbewerbsfähige Quotes bieten, die bisher nur auf Solana oder zentralisierten Börsen verfügbar waren.

Um Prop AMMs im EVM zu ermöglichen, erinnern wir uns an einen der Erfolgsfaktoren auf Solana:

· Schutz durch Updates am Blockanfang: Auf Solana stehen Prop AMM-Updates am Blockanfang und schützen Market Maker vor Front-Running. Updates stehen ganz oben, weil sie extrem wenig Compute Units verbrauchen und selbst bei niedrigen Gebühren ein hohes Fee/CU-Verhältnis erzielen, besonders im Vergleich zu Swaps.

Wie bringt man also Prop AMM-Updates an den Blockanfang einer Layer-2-EVM-Chain? Es gibt zwei Wege: Entweder man senkt die Schreibkosten oder man schafft einen Prioritätskanal für Prop AMM-Updates.

Da günstige SSTOREs wegen des State-Growth-Problems im EVM nicht praktikabel sind (sie würden zu Spam führen), bleibt die Schaffung eines Prioritätskanals für Prop AMM-Updates als gangbare Lösung – und darauf liegt der Fokus dieses Artikels.

@MarkToda vom Uniswap-Team hat einen neuen Ansatz vorgeschlagen, der globale Speicher-Smart Contracts + spezielle Blockbuilder-Strategien kombiniert:

So funktioniert es:

· Global Storage Contract: Ein einfacher Smart Contract dient als öffentliches Key-Value-Storage. Market Maker schreiben Preiskurvenparameter in diesen Contract (z.B. set(ETH-USDC_CONCENTRATION, 4000)).

· Builder-Strategie: Das ist der entscheidende Off-Chain-Bestandteil. Der Blockbuilder erkennt Transaktionen an den Global Storage Contract, reserviert die ersten 5–10% des Block-Gas für diese Updates und sortiert sie nach Gebühr, um Spam zu verhindern.

Wichtig: Transaktionen müssen direkt an die Global Storage-Adresse gesendet werden, sonst ist keine Priorisierung am Blockanfang garantiert.

Ein Beispiel für einen Custom Block Building Algorithmus findet sich in rblib.

Prop AMM Integration: Der Prop AMM Contract des Market Makers liest die Preiskurvendaten beim Swap aus dem Global Storage Contract und stellt so Quotes bereit.

Diese Architektur löst zwei Probleme elegant:

1. Schutz: Die Builder-Strategie schafft einen „Fast Lane“-Kanal, der sicherstellt, dass alle Preisupdates im Block vor den Trades ausgeführt werden und Front-Running verhindert wird.

2. Kosteneffizienz: Market Maker konkurrieren nicht mehr mit allen DeFi-Nutzern um hohe Gaspreise für Blocktop-Transaktionen, sondern nur noch im lokalen Gebührenmarkt für die reservierten Update-Slots, was die Kosten erheblich senkt.

Die Nutzertrades werden dann auf Basis der Preiskurve ausgeführt, die der Market Maker zu Beginn des Blocks aktualisiert hat, was Frische und Sicherheit der Quotes garantiert. Dieses Modell reproduziert die günstige und priorisierte Update-Umgebung von Solana im EVM und ebnet Prop AMMs auf EVM den Weg.

Allerdings gibt es bei diesem Modell auch einige Nachteile, die ich am Ende des Artikels zur Diskussion stelle.

Fazit

Die Machbarkeit von Prop AMMs hängt davon ab, das zentrale ökonomische Problem zu lösen: Günstige und priorisierte Ausführung, um Front-Running zu verhindern.

Obwohl die Standard-EVM-Architektur solche Operationen teuer und riskant macht, bieten neue Designs verschiedene Lösungswege. Die Kombination aus On-Chain Global Storage Smart Contracts und Off-Chain Builder-Strategien schafft einen dedizierten „Fast Lane“-Kanal, der Updates am Blockanfang garantiert und einen lokalen, kontrollierten Gebührenmarkt etabliert. Das macht Prop AMMs nicht nur im EVM möglich, sondern könnte auch für alle EVM-DeFi-Anwendungen, die auf Blocktop-Oracle-Updates angewiesen sind, revolutionär sein.

Offene Fragen

· Ist die Geschwindigkeit von 200ms Flashblocks für Prop AMMs im EVM ausreichend, um mit Solanas kontinuierlicher Architektur zu konkurrieren?

· Auf Solana stammt der Großteil des AMM-Volumens von einem einzigen Aggregator, Jupiter, der ein SDK für AMM-Integrationen bereitstellt. Auf Layer 2 EVM ist das Volumen auf mehrere Aggregatoren verteilt und es gibt kein gemeinsames SDK – ist das eine Herausforderung für Prop AMMs?

· Wie werden Prop AMM-Updates auf Solana mit nur etwa 100 CU realisiert?

· Das Fast Lane-Modell garantiert nur Updates am Blockanfang. Wenn es mehrere Swaps in einem Flashblock gibt, wie kann der Market Maker die Preise zwischen diesen Swaps aktualisieren?

· Ist es möglich, optimierte EVM-Programme in Yul oder Huff zu schreiben, ähnlich wie Pinocchio-Optimierungen auf Solana?

· Wie schneiden Prop AMMs im Vergleich zu RFQ ab?

· Wie verhindert man, dass Market Maker im Block N gute Quotes anbieten, um Nutzer anzulocken, und dann im Block N+1 auf schlechte Quotes umstellen? Wie verhindert Jupiter das?

· Jupiter Ultra V3s Ultra Signaling ermöglicht es Prop AMMs, zwischen schädlichem und harmlosen Traffic zu unterscheiden und engere Quotes anzubieten. Wie wichtig sind solche Aggregator-Features für Prop AMMs im EVM?

Originalartikel