Es wird Zeiten geben, in denen eine App eine beliebige Nachricht signieren muss. Diese Funktionalität existiert in Wallets in Eth, aber wir bieten derzeit keine Funktion dafür in Stacks-Apps an.
Es wird vorgeschlagen, dass wir ein Äquivalent zu https://eips.ethereum.org/EIPS/eip-712 erstellen sollten
aus Zwietracht:
ok, also in der Eth-Welt gibt es Tonnen von willkürlichen Nachrichtenunterzeichnungsrechten, für DeFi und DeX und so weiter
Früher war es immer so, dass man einen Order-Hash signiert hat, aber das ist für den User nicht sehr lesbar. (Das MetaMask-Popup zeigt Ihnen nur eine Hex-Zeichenfolge, Sie haben keine Ahnung, was Sie wirklich signieren.)
EIP712 hat eine Struktur (in json) definiert, die es ermöglicht, zu zeigen, woraus dieser Bestell-Hash bestand
Sie sehen also die tatsächlichen Felder, die in die Generierung des von Ihnen signierten Hashes eingeflossen sind
Danke, dass du das gepostet hast! Ich finde so ein Feature ist entscheidend.
Danke, dass du das gepostet hast! Ich finde so ein Feature ist entscheidend.
Ich stimme zu, und ich denke, viele im Team würden auch zustimmen 👍 Ich werde daran arbeiten, dieses Problem zu aktualisieren, während wir darüber sprechen.
@MarvinJanssen Haben Sie etwas dagegen, die Anwendungsfälle anzugeben, die Sie kurzfristig bauen möchten, um die Prioritäten abzuwägen?
@markmhx kurz gesagt, es gibt wirklich nur einen Grund, warum ich es brauche.
Ich erstelle eine serverseitige Komponente, die Bucket-URLs von Benutzer-Apps verfolgt (für Zonendateien). Um diese API zu sichern, sollte der Benutzer seine Bucket-URL mit Connect signieren. Der Server löst dann den gemeldeten BNS-Namen des Benutzers über den BNS-Vertrag auf und verwendet den entsprechenden Prinzipal, um die Signatur zu überprüfen. Ich muss im Grunde überprüfen, ob eine bestimmte Nachricht tatsächlich von einem Auftraggeber stammt, der einen Namen auf BNS besitzt. Wenn Sie alternative Lösungen haben, lassen Sie es mich wissen. Mein Backup-Plan sah vor, einen einfachen Clarity-Vertrag einzuführen und den Benutzer einen Beweis per Vertragsanruf einreichen zu lassen, aber das macht es zu einer Problemumgehung für eine Problemumgehung für eine Problemumgehung ...
Es gibt 2 andere Hauptanwendungsfälle, die ich gesehen habe, dass Signaturen auf Eth verwendet werden:
@psq ja, langfristig brauchen wir es für DeFi und DeX und Plattformen, die einen serverseitigen Abgleich durchführen, für den Benutzersignaturen erforderlich sind. (Wie 0x Protocol und Wyvern auf Ethereum.)
Danke für den zusätzlichen Kontext 🙏 Ich weise Jasper zu, damit er entwerfen kann.
Ich sehe, das ist in der Icebox @markmhx . Bedeutet das, dass es in einem späteren Sprint berücksichtigt wird? @MarvinJanssen wartet auf Updates 🙂
Ich habe dieses Problem zurück in das Kanban-Backlog verschoben.
Beachten Sie, dass wir nicht mehr gegen 2-wöchige Sprints arbeiten, sondern eher an der schrittweisen Lieferung von Prioritäten, wie sie sich im Rückstand von oben nach unten widerspiegeln.
Ich bin voll und ganz dabei, ein System für signierte typisierte Datenstrukturen zu evaluieren, aber das ist eine viel größere technische Aufgabe, die wir meiner Meinung nach nicht zuerst übernehmen sollten. Der Hauptvorteil der strukturierten Daten sind gebührenfreie On-Chain-Transaktionen mit Logik, die an die Daten in dieser Signatur gebunden ist. Allerdings zwei Dinge:
Strings sind derzeit der offensichtlichste Anwendungsfall für Stacks. Dies würde den sehr häufigen Anwendungsfall ermöglichen, einem Benutzer, der nachweisen kann, dass er eine STX-Adresse besitzt, Off-Chain-Zugriff zu gewähren. Zum Beispiel eine Web-App, die bestimmte Funktionen bietet, wenn Sie ein NFT besitzen.
Um die Anwendungsfälle konkreter zu machen:
Während eines Gesprächs mit @MarvinJanssen und @GinaAbrams wurde gestern festgestellt, dass die .BTC-App keinen dringenden Bedarf an willkürlicher Nachrichtensignierung hat, es sei denn, zwei Dinge passieren nacheinander:
Die beliebige Nachrichtensignaturroute ist im Grunde ein Fallback auf die oben genannten Routen, die in der aufgeführten Reihenfolge bevorzugt werden. Es würde bedeuten, signierte Nachrichten mit Zonendateidaten an einen zentralisierten Server zu senden, was dem Endbenutzer die Kosten für das Signieren einer Transaktion ersparen würde, aber auch die unerwünschte Beteiligung einer zentralisierten Partei nach sich ziehen würde.
@agraebe @diwakergupta Ich melde mich nächste Woche bei splat, um zu sehen, wie die Atlas-Bereitstellungspläne laufen, damit wir @MarvinJanssen hier ein Update in Bezug auf das Timing und die Auswirkungen auf seine Optionen geben können.
Er freut sich, ein oder zwei Wochen zu warten, um zu sehen, ob wir die Korrekturen live im Mainnet erhalten und ihm die Arbeit für beide Problemumgehungen ersparen können.
Dies ist von unschätzbarem Wert, da die Verwendung von Signaturen aus der Identität den Besitz eines Namens und einer ganzen Menge Dinge beweisen würde, insbesondere wenn es um Off-Chain-Operationen geht, 100% dafür
Hilfreichster Kommentar
Während eines Gesprächs mit @MarvinJanssen und @GinaAbrams wurde gestern festgestellt, dass die .BTC-App keinen dringenden Bedarf an willkürlicher Nachrichtensignierung hat, es sei denn, zwei Dinge passieren nacheinander:
Die beliebige Nachrichtensignaturroute ist im Grunde ein Fallback auf die oben genannten Routen, die in der aufgeführten Reihenfolge bevorzugt werden. Es würde bedeuten, signierte Nachrichten mit Zonendateidaten an einen zentralisierten Server zu senden, was dem Endbenutzer die Kosten für das Signieren einer Transaktion ersparen würde, aber auch die unerwünschte Beteiligung einer zentralisierten Partei nach sich ziehen würde.
@agraebe @diwakergupta Ich melde mich nächste Woche bei splat, um zu sehen, wie die Atlas-Bereitstellungspläne laufen, damit wir @MarvinJanssen hier ein Update in Bezug auf das Timing und die Auswirkungen auf seine Optionen geben können.
Er freut sich, ein oder zwei Wochen zu warten, um zu sehen, ob wir die Korrekturen live im Mainnet erhalten und ihm die Arbeit für beide Problemumgehungen ersparen können.