Diese Woche habe ich die vollständige Reihe der Cross-Chain-Verträge abgebildet – nicht nur die fünf wichtigsten –, weil die Multichain-Dokumentation auf zwei zusätzliche Verträge verweist, die in den standardmäßigen Integrationsanleitungen nicht auftauchen.

BN254CertificateVerifier und ECDSAOperatorTableUpdater.
Zwei unterschiedliche Aufgaben. Der ECDSAOperatorTableUpdater erhält von permissionless Relayern mit BLS signierte Merkle-Roots und wendet Operator-Tabellen-Updates auf Ziel-Chains an, wenn sich der Operator-Set auf Ethereum ändert. Der BN254CertificateVerifier verifiziert auf Ziel-Chains BLS-Aggregatsignaturen – konkret mithilfe der BN254-Kurve (alt_bn128), die die Newton-BLS-Implementierung verwendet.
Nicht sieben Kernverträge. Fünf Kernverträge plus zwei Cross-Chain-spezifische Komponenten, die insbesondere für Deployments auf Ziel-Chains relevant sind – nicht nur für die Source-Chain.

Ich denke tatsächlich, dass diese Unterscheidung einen nützlichen Rahmen für die Deploymentsplanung liefert. Teams, die Newton auf einer einzelnen Chain bereitstellen, begegnen möglicherweise nie dem BN254CertificateVerifier. Teams, die Cross-Chain-Deployments durchführen, brauchen beides und müssen verstehen, wie es mit den fünf Hauptverträgen zusammenspielt.

Die Frage ist, ob diese beiden Verträge separate Security Audits durch Teams erfordern, die Newton bereitstellen, und ob sie die gleichen formalen Security-Garantien tragen wie die fünf Kernverträge, die in der Architektur-Dokumentation aufgeführt sind.
@NewtonProtocol $NEWT #Newt $LAB $TLM