Als ich die Regeln für das Staking von @BabylonLabs_io nachgeschlagen habe, ist ich plötzlich stehen geblieben. In derselben Transaktion tauchten die öffentlichen Schlüssel des Stakers und des Finality Providers zweimal auf. Einmal in der OP_RETURN-Ausgabe und einmal im Taproot-Skriptpfad.
Ich dachte, es reicht, die Daten nur einmal zu speichern. Der öffentliche Schlüssel in OP_RETURN wird dafür verwendet, dass Babylon die Staking-Transaktion erkennt und sie analysiert, und der öffentliche Schlüssel im Taproot-Skriptpfad wird für die Validierung und Ausführung der Ausgabebedingungen verwendet, die in dem Protokoll definiert sind (einschließlich Skriptpfaden für Slashing usw.). An beiden Stellen wird dieselbe Schlüsselgruppe gespeichert, aber der Zweck ist völlig unterschiedlich.
Das ist genau der Teil, den niemand in die PPT packt. Wenn irgendein Teil fehlt, kann diese Transaktion ihre volle Wirkung als Staking-Transaktion im Sinne der Babylon-Spezifikation nicht entfalten.
Ich habe das Handy erst mal weggelegt und eine Weile nachgedacht: Ist das ein redundantes Design oder eine notwendige doppelte Bestätigung? Vielleicht ist es beides.
#baby $BABY
Ich dachte, es reicht, die Daten nur einmal zu speichern. Der öffentliche Schlüssel in OP_RETURN wird dafür verwendet, dass Babylon die Staking-Transaktion erkennt und sie analysiert, und der öffentliche Schlüssel im Taproot-Skriptpfad wird für die Validierung und Ausführung der Ausgabebedingungen verwendet, die in dem Protokoll definiert sind (einschließlich Skriptpfaden für Slashing usw.). An beiden Stellen wird dieselbe Schlüsselgruppe gespeichert, aber der Zweck ist völlig unterschiedlich.
Das ist genau der Teil, den niemand in die PPT packt. Wenn irgendein Teil fehlt, kann diese Transaktion ihre volle Wirkung als Staking-Transaktion im Sinne der Babylon-Spezifikation nicht entfalten.
Ich habe das Handy erst mal weggelegt und eine Weile nachgedacht: Ist das ein redundantes Design oder eine notwendige doppelte Bestätigung? Vielleicht ist es beides.
#baby $BABY