LayerZero DVNs verifizieren Cross-Chain-Nachrichten; Executors automatisieren deren Zustellung auf der Zielkette. Erforderliche DVNs müssen alle attestieren, während optionale DVNs eine separate Schwelle erfüllen. Ein Executor kann eine fehlende erforderliche Attestierung nicht ersetzen, weshalb Verifizierungsfehler und Zustellungsfehler unterschiedliche Wiederherstellungsschritte benötigen.
Dieser letzte Punkt verschwindet oft hinter einer Liste von Provider-Logos. Die Sicherheit des Assets hängt davon ab, welche Provider der Vertrag tatsächlich auf jeder Route zum Zeitpunkt der Übertragung erfordert.
Was ein DVN attestiert
Ein Decentralized Verifier Network prüft die Nachricht der Quellkette und reicht eine Attestierung ein, die mit ihrer Nutzlast verknüpft ist. Die empfangende Nachrichtenbibliothek bewertet die erforderlichen Attestierungen, bevor eine Nachricht für die Zustellung teilnahmeberechtigt wird. Jedes DVN kann seine eigene Verifizierungsmethode verwenden. DVN-Sicherheitsstack.
Das „Netzwerk“ im Namen sollte keine Recherche zum Operator ersetzen. Du musst immer noch dessen Infrastruktur, Schlüssel und Fehlermodi verstehen. Zwei Provider können unterschiedliche Namen haben und dennoch von derselben Datenquelle oder Betriebsumgebung abhängen.
Die Anwendung wählt eine Kombination. Ein einzelner erforderlicher Provider schafft eine andere Vertrauensannahme als mehrere unabhängige erforderliche Provider. Die Wahl ändert, was ein Angreifer kompromittieren müsste und was ein Ausfall unterbrechen könnte.
Ein Ausfall und eine Kompromittierung beeinflussen diese Wahl unterschiedlich. Ein offline befindlicher Verifizierer kann verhindern, dass eine legitime Nachricht fortgeschritten wird. Ein kompromittierter Verifizierer kann eine falsche Nachricht attestieren. Eine Richtlinie sollte gegen beide Situationen bewertet werden.
Verifizierer entscheiden über die Annahme. Executors liefern.
Dieses Beispiel trennt die Sicherheitsrichtlinie von der Zieltransaktion.
Beispiel für eine DVN-Richtlinie
Erforderliches A + erforderliches B + mindestens eine optionale Attestierung
Seine Attestierung ist obligatorisch.
Zusätzliche optionale Attestierungen können es nicht ersetzen.
Beide können die illustrierte optionale Schwelle erfüllen.
Illustrative Policy, keine empfohlene Produktionskonfiguration oder Behauptung über die Unabhängigkeit der Operatoren.
Erforderlich bedeutet erforderlich
Ein erforderlicher DVN muss bestätigen. Das Hinzufügen optionaler DVNs gibt der Anwendung nicht automatisch eine Möglichkeit, einen fehlenden erforderlichen DVN zu überspringen. Optionale Bestätigungen erfüllen ihre eigene konfigurierte Schwelle.
Beispielsweise kann eine Richtlinie A und B plus einen Provider aus einem optionalen Set, das C und D enthält, erfordern. Wenn B offline ist, wird die Richtlinie auch dann nicht erfüllt, wenn sowohl C als auch D bestätigen. Wenn D offline ist, kann C den optionalen Teil erfüllen, während A und B weiterhin notwendig bleiben. Dies ist eine hypothetische Konfiguration, die die Regel verdeutlicht. LayerZero-Verifizierungsmodell.
Diese Unterscheidung hat einen operativen Kostenfaktor. Mehr unabhängige erforderliche Zeugen können die Akzeptanzregel stärken, während sie gleichzeitig mehr Abhängigkeiten für eine erfolgreiche Zustellung schaffen. Ein Team muss die Planung an der Verfügbarkeit jeder obligatorischen Komponente ausrichten.
Die richtige Frage ist, was das Asset schützen muss. Ein gefälschter Mint für einen weit verbreiteten Collateral-Token kann andere Lending- oder Trading-Anwendungen beeinträchtigen. Diese nachgelagerten Risiken können strengere Anforderungen rechtfertigen als eine Anwendungsmeldung mit geringem Wert.
Diversität muss einen echten Ausfall überstehen
Unterschiedliche Provider-Namen sind ein Anfang. Die strengere Prüfung klärt, ob die Provider sich Datenquellen, Cloud-Systeme, Signatur-Infrastrukturen oder Deployment-Pipelines teilen. Ein gemeinsames Versagen kann den Zweck der Nutzung mehrerer Zeugen zunichtemachen.
Die Produktionsanleitung von LayerZero diskutiert die Diversität von Operatoren und Infrastruktur neben den Verifizierungsmethoden. Sie warnt auch davor, Beispiel-Einstellungen als Produktions-Sicherheitsrichtlinie zu behandeln. Produktions-DVN-Konfiguration.
Betrachte Provider, die alle dieselben fehlerhaften Source-Chain-Daten lesen. Ihre Signaturen können unabhängig sein, während die Beobachtung dahinter falsch ist. Ein stärkeres Design reduziert diese gemeinsame Abhängigkeit, anstatt lediglich eine weitere Signatur hinzuzufügen.
Für einen Nutzer kann es schwierig sein, diese Informationen unabhängig zu ermitteln. Das macht explizite Offenlegungen durch den Issuer wertvoll. Ein Projekt, das die erforderlichen Provider benennt, die Richtlinie erklärt und seine Live-Konfiguration veröffentlicht, bietet mehr zur Bewertung als eine generische „secured by LayerZero“-Aussage.
Executors verarbeiten die Zieltransaktion
Nach der Verifizierung muss jemand eine Transaktion auf der Zielkette einreichen und finanzieren. Ein Executor automatisiert diese Arbeit unter den Ausführungsoptionen der Nachricht. Verifizierte Nachrichten können auch über permissionless-Endpunktaufrufe ausgeführt werden. Executor-Dokumentation.
Ein Ausfall der Zustellung kann daher eine legitime Nachricht verzögern, ohne dem Zustelldienst die Erlaubnis zu geben, eine gültige Nachricht zu erfinden. Die Verifizierungsprüfungen bleiben eine separate Hürde. Diese Unterscheidung ist nützlich, wenn ein steckengebliebener Transfer interpretiert wird.
Das macht die Zustellung nicht irrelevant. Die Anwendung kann darauf vertrauen, dass Gas, der angehängte Wert oder spätere Aufrufe korrekt verarbeitet werden. Eine verifizierte Nachricht benötigt immer noch genügend Ressourcen und eine kompatible Ziellogik, um ihre beabsichtigte Aktion abzuschließen.
Ein Wiederherstellungsprozess sollte den Betreibern sagen, wie sie die fehlgeschlagene Phase identifizieren und eine legitime ausstehende Nachricht ausführen können. Er sollte zudem einen Ausführungsfehler von einer nicht erfüllten Verifizierungspolitik unterscheiden. Das Bezahlen von mehr Gas auf der Zielkette kann keine erforderliche Attestierung ersetzen, die nie angekommen ist.
Bestätigungen tauschen Geschwindigkeit gegen Risiko
Die Verifizierung benötigt eine Regel dafür, wann ein Ereignis der Quellkette ausreichend abgewickelt ist, um ihm zu vertrauen. Das Warten auf zusätzliche Bestätigungen kann das Nutzererlebnis verlangsamen, während es das Risiko einer Chain-Reorganisation reduziert.
Eine Aktion auf der Zielkette, die auf einem Quellereignis basiert, das später verschwindet, schafft ein Abrechnungsproblem. Bei einem Token-Transfer könnte die Zielkette einen Wert gutgeschrieben haben, dessen Quellabbuchung in der kanonischen Historie nicht mehr existiert. Finalitätsannahmen gehören daher in die Sicherheitsbeschreibung des Assets.
Die richtige Einstellung hängt vom Netzwerk und der Route ab. Eine Bestätigungszahl, die aus einem Entwicklungsbeispiel kopiert wurde, begründet keine sichere Produktionspolitik. Produktionsanleitungen und das eigene Finalitätsmodell der Chain sollten die Wahl beeinflussen. LayerZero-Produktionsanleitung.
Bei einem Finanzprodukt stellt sich die Frage, welche Verzögerung die Nutzer im Verhältnis zum potenziellen Verlust akzeptieren können. Eine Schnittstelle sollte die Erwartungen entsprechend setzen. Einen langsameren Transfer als „kaputt“ zu bezeichnen, kann Teams dazu drängen, eine Einstellung zu schwächen, die aus einem bestimmten Grund existiert.
Die Administration steht über der Policy
Der Eigentümer oder die delegierte Autorität kann die Application-Peers und die Konfiguration beeinflussen. Selbst eine sorgfältig gewählte Verifizierungsrichtlinie hängt von der Sicherheit und Governance des Kontos ab, das sie ändern kann. OApp technische Referenz.
Frage nach, wer diese Autorität kontrolliert und wie Änderungen sichtbar werden. Eine Multisig-Richtlinie hilft nur in dem Maße, in dem ihre Unterzeichner und operativen Verfahren eine unabhängige Kontrolle bieten. Eine Zeitverzögerung hilft nur, wenn jemand die ausstehende Änderung überwacht und reagieren kann.
Transfer-Limits und Notfall-Pausen können bestimmte Vorfälle eindämmen. Sie geben den Betreibern auch Befugnisse, die die Nutzer verstehen sollten. Eine Pause kann das Angebot schützen, während sie einen Inhaber daran hindert, einen geplanten Transfer oder Ausstieg abzuschließen.
Bei RWA-Assets interagieren diese Befugnisse mit den Verpflichtungen des Herausgebers und den Einschränkungen der Investoren. Eine Cross-Chain-Verifizierung prüft eine Nachricht; sie regelt nicht die rechtlichen Ansprüche, die an den Token gebunden sind. Die RWA-Einführung deckt diesen separaten Anspruch ab.
Prüfe die Route, die du verwendest
Notiere die Quell- und Zielverträge, ihre Peer-Beziehung und die wirksamen Verifizierungsanforderungen. Prüfe die Bestätigungsrichtlinie, den Delivery-Provider und etwaige Transfer-Limits. Identifiziere dann, wer diese Einstellungen ändern kann.
Einen Standardwert beizubehalten, ist immer noch eine Konfigurationsentscheidung. Einige Pfade enthalten einen Dead-DVN-Platzhalter und können keine Nachrichten verifizieren, bis die Anwendung funktionierende Provider auswählt. Die aktuelle Dokumentation empfiehlt explizite Produktions-Einstellungen und einen erforderlichen Verifizierer, der unabhängig von LayerZero Labs ist. Prüfe die wirksame Konfiguration, anstatt anzunehmen, dass ein Standardwert für dein Asset bereit ist. Anleitung zur Standardkonfiguration.
Tue dies für die tatsächliche Transferrichtung. Eine sicher aussehende Konfiguration auf einer Route beweist nicht, dass jede andere Route die gleiche Richtlinie hat. Eine netzwerkweite Support-Behauptung beweist auch nicht, dass jeder Provider für dein Asset verfügbar ist.
Wenn dein Interesse die Token-Buchhaltung rund um diese Prüfungen ist, lies den OFT-Erklärartikel zum Angebot. Wenn du Provider der breiteren Infrastruktur vergleichst, nutze LayerZero vs. Chainlink CCIP, das denselben routenspezifischen Ansatz verfolgt.