Der Ethereum-Mitwirkende Marchhill hat einen Entwurfsvorschlag eingereicht, um generische Proof-Verifizierung und gesponserte Stapelverarbeitung zu ermöglichen, sodass mehrere Transaktionsansprüche einen Proof teilen können, während separate Zahlungen und Signaturen erhalten bleiben.
Zusammenfassung
- Sponsoren könnten für Stapel-Proofs zahlen, während Mitgliedstransaktionen für ihre individuellen Ansprüche zahlen.
- Gültige Teilmengen könnten in einen Block aufgenommen werden, ohne dass Mitglieder ihre Transaktionen erneut signieren müssen.
- Vorgeschlagene Gebühren und Ressourcenlimits bleiben vorläufig, wobei die Aktivierung von Leistungsmessungen abhängt.
- Die Einreichung ist ein Entwurfs-Pull-Request, ohne zugewiesene EIP-Nummer oder Mainnet-Aktivierungsdatum.
Marchhills Vorschlag, der am 13. November im EIP-Repository von Ethereum eingereicht wurde, würde das in EIP-8288 reservierte LEANSTARK_SCHEME aktivieren und Regeln für gesponserte Stapel einführen. Die Einreichung befindet sich noch in Entwicklung und wurde nicht als Ethereum-Netzwerk-Upgrade übernommen.
Der Entwurf vereint generische Verifizierung, Proof-Identität, Ressourcenlimits, Abhängigkeitszusammenfassungen und Stapelzahlungen in einem Vorschlag. Er ersetzt eine frühere Einreichung, Pull-Request #12654, während eine EIP-Nummer und ein eigener Diskussionsthread noch zugewiesen werden müssen.
Ethereum-Stapel-Proofs würden Sponsor- und Mitgliedszahlungen trennen
Im Zentrum des Entwurfs steht eine Zahlungsvereinbarung, bei der ein Sponsor jedes beibehaltene Stapelblatt abdeckt, eine individuelle Proof-Komponente, die mehrere Ansprüche enthält. Mitgliedstransaktionen würden gemäß ihren eigenen eingereichten Ansprüchen zahlen.
Ein Builder könnte jede gültige Teilmenge aufnehmen, ohne die Mitglieder erneut um eine Signatur zu bitten. Jemand, dessen Transaktion zur Aufnahme bereit wäre, bräuchte demnach nicht allein deshalb eine neue Signatur, weil andere Mitglieder der ursprünglichen Gruppe ausgelassen wurden, so der vorgeschlagene Mechanismus.
Der Entwurf würde individuelle Transaktions-Nonces und -Belege bewahren. Eine Nonce identifiziert den Platz einer Transaktion in der Transaktionssequenz eines Kontos, während ein Beleg ihr Ausführungsergebnis festhält. Das Teilen von Proof-Arbeit würde diese Aufzeichnungen an den separaten Transaktionen belassen.
Die Zahlungszuordnung würde während der Finalisierung geprüft, wobei rekursive Proofs die im Stapel verwendeten Quellen authentifizieren. Die Einreichung unterscheidet die Arbeit, festzustellen, dass Ansprüche gültig sind, von der Arbeit, zu bestätigen, dass die erforderlichen Zahlungen sie begleiten.
Ermäßigte Ansprüche und Sponsorzahlungen würden direkt an Block-Builder gehen. Gewöhnliche Proofs, die eine einzelne Aussage abdecken, blieben für den öffentlichen Mempool geeignet, wo Transaktionen darauf warten, in Blöcke aufgenommen zu werden.
Generische Verifizierung baut auf EIP-8288 auf
Das zugrunde liegende EIP-8288, verfasst von Vitalik Buterin und Thomas Coratger, schlägt vor, kryptografische Signaturen und Proofs außerhalb des Hauptausführungsprozesses von Ethereum zu aggregieren. Transaktionen würden die Aussagen identifizieren, die sie verifiziert haben möchten, und ein rekursiver STARK würde ihre Gültigkeit auf Blockebene feststellen.
STARKs sind kryptografische Proofs, die zeigen, dass eine Berechnung korrekt durchgeführt wurde, ohne dass jeder Verifizierer sie wiederholen muss. Rekursion ermöglicht es einem Proof, andere Proofs zu verifizieren und ihre Ergebnisse zu kombinieren.
EIP-8288 reserviert derzeit das generische leanSTARK-Schema, anstatt seine Verwendung in Abhängigkeitsrahmen zu erlauben. Marchhills Einreichung schlägt vor, diesen Pfad zu aktivieren und die bloße Daten-Hash-Aussage des Basisentwurfs durch einen stabilen Digest zu ersetzen, der eine Liste von Ansprüchen repräsentiert.
Das Design folgt einer früheren Diskussion über kryptografische Verifizierung, einschließlich Buterins Unterstützung für den Umgang mit komplexer Kryptografie durch aggregierte Proofs. Seine Kommentare betrafen die zugrunde liegende Architektur; Marchhills Entwurf legt eine spezifische Verifizierungs- und Zahlungsvereinbarung dar.
Vorgeschlagene Gebühren bleiben kalibrierungsabhängig
Die vorliegende Revision listet vorläufige Gebühren von 15.400 Gas für native Verifizierung und 572.000 Gas für gewöhnliche generische Verifizierung auf. Sie weist 5.100 Gas dem intrinsischen Proof-Anteil, 675.000 Gas einer Blattzahlung und 4.200 Gas einem Stapelanspruch zu.
Blattzahlungen tragen eine separate Gebühr, weil bindende Zahlungen feste Arbeit über die gewöhnliche Verifizierung hinaus hinzufügen, erklärt der Entwurf. Ansprüche und Zahlungen würden keinen zusätzlichen intrinsischen Proof-Anteil verursachen. Die Zahlen erfordern eine gemeinsame Kalibrierung, sodass sie weder einen endgültigen Gebührenplan noch eine bestätigte Ersparnis für Nutzer festlegen.
Zu den Ressourcenkontrollen gehören ein vorläufiges Blocklimit von 16.384 unterschiedlichen Abhängigkeiten, das unabhängig vom Gas angewendet wird, zusammen mit einer entsprechenden Regel zur Eignung der Inklusionsliste. Ein Leaf könnte bis zu 256 Claims enthalten, während ein Proof-Schritt 16 Eingaben haben könnte. Keine der beiden Zahlen ist ein blockweites Limit.
Eine Aktivierung würde Leistungsmessungen über den gesamten Block erfordern
Vor der Aktivierung verlangt der Vorschlag Messungen, die den vollständigen Verarbeitungsablauf, die späte Reparatur durch den Sponsor und die pro Proof anfallenden Gebühren abdecken, die innerhalb der Transaktionsgaslimits liegen, einschließlich des erforderlichen Overheads.
Sein Benchmark-Material unterscheidet gemessene Ergebnisse einzelner Knoten und Einzelmaschinen-Blockergebnisse von modellierten Zahlen für 16 Worker. Der Entwurf verlangt, dass die Belege und verbleibenden Leistungslücken in seinem Benchmark-Material festgehalten werden.
Eine ungültig gemachte Sponsoring-Zusage könnte die Arbeit eines Builders verschwenden, und die Einreichung besagt, dass das Inklusionsgas diese Arbeit nicht erstatten würde. Die konkrete Konstruktion der Commitments und die Kodierungen verbleiben in der festgelegten Proof-System-Spezifikation. Der Vorschlag führt keine neuen Netzwerknachrichten ein.
