Etwas an der Entwicklerdokumentation von Sign hat meine Aufmerksamkeit auf eine Weise erregt, die ich nicht erwartet hatte.
Die meisten Infrastrukturprotokolle, die auf Regierungen oder Institutionen abzielen, haben Entwicklerrichtlinien, die sich wie ein Nachgedanke anfühlen. Der Architekturabschnitt ist ausgereift. Der SDK-Abschnitt umfasst drei Seiten mit ein paar Code-Snippets und einem Link zu einem GitHub-Repo, das seit acht Monaten nicht aktualisiert wurde. Die implizite Botschaft ist, dass echte Integrationen durch Unternehmensverkaufs Gespräche und nicht durch Entwickler, die am Samstagnachmittag Dokumente lesen, stattfinden.
Die Dokumentation des Sign-Builders liest sich anders. Ich habe ein paar Stunden damit verbracht, sie sorgfältig durchzugehen, und was ich hier tun möchte, ist, zu erläutern, wie das Bauen auf dem Sign-Protokoll tatsächlich auf technischer Ebene aussieht, denn ich denke, die Entwicklerebene wird in den meisten Diskussionen über dieses Projekt nicht ausreichend gewürdigt.
Die Grundlage von allem im Sign-Protokoll ist das Schema. Ein Schema ist eine Vorlage, die definiert, wie strukturierte Daten in einer Bestätigung dargestellt werden. Bevor Sie eine Bestätigung erstellen können, benötigen Sie entweder ein bestehendes Schema, das zu Ihrem Anwendungsfall passt, oder Sie müssen ein neues erstellen. Die Dokumentation von Sign beschreibt Schemata als on-chain registriert, was bedeutet, dass sie eine eindeutige Kennung, eine definierte Feldstruktur und einen Resolver haben, der behandelt, wie das Schema während der Verifizierung interpretiert wird.
Die Erstellung eines Schemas über das Sign-SDK scheint in der Dokumentation unkompliziert zu sein. Sie definieren die Feldnamen und ihre Datentypen, geben an, ob das Schema widerrufbar ist, setzen eine Resolver-Adresse, falls Sie benutzerdefinierte on-chain-Logik benötigen, die ausgeführt wird, wenn Bestätigungen, die auf dieses Schema verweisen, erstellt oder widerrufen werden, und registrieren es. Das Schema erhält eine on-chain-ID, die jede Bestätigung, die darauf verweist, tragen wird. Diese ID ist es, die Bestätigungen strukturell vergleichbar macht, wenn verschiedene Aussteller dasselbe Schema verwenden. Zwei verschiedene Regierungsbehörden können Berechtigungen unter Verwendung derselben Schema-ID ausstellen, und ein Prüfer kann sie über eine einzige Schnittstelle vergleichen und abfragen.
Der Prozess zur Erstellung von Bestätigungen baut darauf auf. Durch das Sign-SDK konstruieren Sie ein Bestätigungsobjekt, das auf eine Schema-ID verweist, den Empfänger angibt, die im Schema definierten Datenfelder ausfüllt, eine Ablaufzeit festlegt, falls relevant, und es mit dem Schlüssel des Ausstellers signiert. Die Bestätigung kann vollständig on-chain veröffentlicht, on-chain mit der off-chain gespeicherten Nutzlast verankert oder vollständig off-chain mit einem überprüfbaren Verweis aufbewahrt werden. Die Wahl des Datenplatzierungsmodus erfolgt zum Zeitpunkt der Erstellung der Bestätigung und hat direkte Auswirkungen auf die Gaspreise, die Privatsphäre und die Abfragemöglichkeiten.
Was ich am praktischsten interessant fand, ist das off-chain-Bestätigungsmodell. Für Anwendungsfälle mit sensiblen Daten, die in einem souveränen Deployment die meisten von ihnen ausmachen, ist es nicht angemessen, die vollständige Nutzlast on-chain zu stellen. Der off-chain-Modus von Sign speichert die Bestätigungsnutzlast off-chain, veröffentlicht jedoch einen kryptografischen Hash davon on-chain als Anker. Der Prüfer kann bestätigen, dass die off-chain-Nutzlast mit dem on-chain-Anker übereinstimmt, ohne dass die Nutzlast selbst öffentlich sichtbar ist. Dies ist das Muster, das das Sign-Protokoll für echte nationale Identitäts- und Kapitalverteilungsprogramme verwendbar macht, bei denen Bürgerdaten nicht auf einem öffentlichen Ledger offengelegt werden können.
Das Widerrufs-System ist es wert, sorgfältig verstanden zu werden, da es direkt relevant dafür ist, wie Berechtigungen in Live-Deployments funktionieren. Sign unterstützt Widerruf auf der Ebene der Bestätigung, was bedeutet, dass ein Aussteller eine spezifische Bestätigung widerrufen kann, nachdem sie erstellt wurde. Der Widerruf wird on-chain aufgezeichnet und ist über SignScan abfragbar. Für ein nationales Identitäts-Deployment ist dies der Mechanismus, der Situationen wie das Aussetzen einer Berufslizenz, das Ablaufen einer Berechtigungszertifizierung oder das Zurückziehen einer Compliance-Zertifizierung behandelt. Der Widerruf löscht die ursprüngliche Bestätigung nicht. Er kennzeichnet sie als widerrufen auf eine Weise, die jeder Prüfer, der den aktuellen Status überprüft, erkennen wird.
SignScan ist die Abfrageebene, die all dies zusammenführt. Für einen Entwickler, der das Sign-Protokoll in ein größeres System integriert, bietet SignScan REST- und GraphQL-APIs zur Abfrage von Bestätigungen nach Schema, nach Aussteller, nach Empfänger, nach Zeitrahmen und nach Widerrufsstatus. Das bedeutet, dass ein Compliance-Dashboard für ein Regierungsprogramm strukturierte Bestätigungsdaten in Echtzeit abrufen kann, anstatt rohe on-chain-Transaktionen zu analysieren. Ein Prüfer, der ein Verteilungsprogramm überprüft, kann alle Bestätigungen abfragen, die unter einem bestimmten Schema in einem bestimmten Zeitraum ausgestellt wurden, und erhält strukturierte Ergebnisse, die bereits für die Inspektion formatiert sind.
Die Sign-Entwicklerplattform, die in der Dokumentation als SDP bezeichnet wird, bietet zusätzliche Werkzeuge zur Verwaltung von Schemata, zur Überwachung von Bestätigungsaktivitäten und zum Testen von Integrationen. Ich hatte bisher noch nicht die Möglichkeit, praktisch mit SDP zu arbeiten, also arbeite ich hier mit der Dokumentation, was eine Einschränkung ist, über die es sich lohnt, transparent zu sein.
Die in der Dokumentation von Sign aufgeführten unterstützten Netzwerke umfassen mehrere große Chains, was bedeutet, dass Bestätigungen über verschiedene Blockchain-Umgebungen ausgegeben und überprüft werden können. Für ein souveränes Deployment, das möglicherweise auf einer dedizierten L2 oder einer genehmigten Chain läuft, ist das cross-chain-Bestätigungsmodell relevant. Das Omni-Chain-Design des Sign-Protokolls bedeutet, dass die Evidenzebene nicht an ein Netzwerk gebunden ist, was wichtig ist, wenn Sie eine Infrastruktur aufbauen, die mit mehreren bestehenden Schienen interoperieren muss.
Meine ehrliche Einschätzung, nachdem ich die Builder-Dokumentation durchgegangen bin: Die grundlegenden Primitiven sind gut gestaltet, und das SDK scheint wirklich benutzbar zu sein. Das Schema- und Bestätigungsmodell ist klar genug, dass ein Entwickler, der die Konzepte versteht, sich relativ schnell orientieren kann. Das off-chain-Bestätigungsmodell mit on-chain-Verankerung löst das Privatsphäreproblem auf praktische Weise.
Die Lücke, über die ich mir noch unsicher bin, ist die Distanz zwischen einem Entwickler, der erfolgreich Bestätigungen in einer Testnetz-Umgebung erstellt, und einem produktionsreifen souveränen Deployment, das mit nationaler Concurrentität läuft. Die Dokumentation von Sign behandelt Architektur und Werkzeuge gut. Die operationale Härtung, die Infrastruktur für das Schlüsselmanagement, die Verfahren zur Katastrophenwiederherstellung, die Prozesse zur Schema-Governance für einen Multi-Agenturen-Einsatz, das sind die Schichten, die über das hinausgehen, was jede SDK-Dokumentation vollständig beschreiben kann.
Das ist keine spezifische Kritik an Sign. Es ist die ehrliche Realität jeder Infrastrukturebene in diesem Maßstab. Die Entwicklererfahrung sieht von meiner Perspektive aus solide aus.