Bir did:solidus DID'sini 10 Satırın Altında Çözümleyin

"Bir DID'yi çözümlemek" tek bir şey demektir: ağa bir did:solidus tanımlayıcısı verip karşılığında DID Belgesini, yani ardındaki açık anahtarları ve yetenekleri geri almak.

curl -X POST https://rpc.solidus.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "solidus_didResolve",
    "params": ["did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J"],
    "id": 1
  }'

Sekiz satır, tek bir bağımlılık (curl), tek bir gerçek ağ gidiş dönüşü; bir taklit değil, bir sabit veri değil, önce indirip güvenmeniz gereken bir ikili dosya değil. Kendi did:solidus tanımlayıcınız olduğunda onu yerine koyun. Bunu yapmadan önce bilinmeye değer bir davranış: zincire hiç demirlenmemiş bir DID, bir hata yerine "result": null olarak çözümlenir, dolayısıyla bir yazım hatası ile gerçekten eksik olan bir DID dışarıdan birebir aynı görünür.

Ne geri geliyor

Yukarıdaki çağrı bir DID Belgesi döndürür: her DID'nin çözümlendiği kayıt. Devam etmeden önce adlandırmaya değer üç alan: verification_method bu tanımlayıcıya iliştirilmiş açık anahtarları listeler; authentication o anahtarlardan hangisinin "ben bu DID'yim"i kanıtlayabileceğini adlandırır (sınama-yanıt, oturum açma); assertion_method hangi anahtarların ifade imzalayabileceğini adlandırır, birine Doğrulanabilir Kimlik Bilgisi vermek dahil. Biçim konusunda bir not, çünkü ders kitabı DID Core JSON-LD'si bekliyorsanız takılacaksınız: ham RPC, zincirin kendi snake_case alan adlarını sunar, yani verification_method, verificationMethod değil, DID Core'un camelCase serileştirmesi değil. Altta yatan yapı DID Core'unkidir; hat biçimi zincirin kendisidir. Alan alan tam anlatım, yani service, capability_invocation, recovery_policy ve etkin olmayan bir DID'nin belgesinin nasıl göründüğü, 008 — Bir DID Belgesinde Ne Var sayfasında yaşar; bu sayfa "işte çağrı ve işte kabaca neye baktığınız"da durur.

Bu neyi kanıtlar, neyi kanıtlamaz

Uzlaşma, blok üretimi, doğrulayıcı sayısı ya da iş hacmi hakkında hiçbir şey kanıtlamaz: durum ağacına karşı tek bir okuma bir yük testi değildir ve buradaki hiçbir şey ağın başka bir iş yükü altındaki hızı ya da ölçeği hakkında bir iddia olarak okunmamalıdır. Ayrıca bugün, diğer DID yöntemlerinin yanında DIF'in Universal Resolver'ı üzerinden yönlendirilmiş bir arama değil, doğrudan Solidus'un kendi uç noktasına yapılan bir çağrıdır; o entegrasyon henüz gerçekleşmedi.

Farklı bir tanımlayıcıya karşı deneyin

Yukarıdaki parçacıkla yapılabilecek en yararlı şey onu kırmaktır: var olduğunu bildiğiniz bir DID'yi çözümleyin, sonra uydurduğunuz birini çözümleyin. Birincisi bir belge döndürür; ikincisi null döndürür. O ayrım göründüğünden daha çok önem taşır: ikili bir DID'nin dayandığı davranışın aynısıdır. İkili, doğrulayıcı başına bir tanımlayıcı kasıtlı olarak zincire hiç demirlenmez, dolayısıyla birini bu aynı şekilde çözümlemek tam olarak yukarıdaki null durumunu döndürür; bilerek. Bunun neden bir hata değil bir özellik olduğu ve dayanan bir tarafa bunun yerine gerçekte neyin sunulduğu için bkz. 001 — İkili DID'ler.

Sırada nereye

Sunum ve çözümlemenin uçtan uca nasıl bir araya geldiği için, bu sayfanın bağlandığı genel bakış sayfası how-it-works'tür. Bu çağrının altındaki kavram, yani bir DID'nin gerçekte ne olduğu ve özellikle did:solidus'un neden "bir W3C standardı" değil de W3C DID Method Registry içinde kayıtlı olduğu için bkz. 003 — DID Nedir. Az önce geri gelenin tam yapısı için bkz. 008 — Bir DID Belgesinde Ne Var. Ve bu tek işlenmiş örnekten bağımsız olarak çözümlemenin kendisine dair kanonik, şartname düzeyindeki referans için Lexicon'un DID Çözümlemesi girdisine bakın; bu sayfa o girdinin işlenmiş örneğidir, yerine geçen bir şey değil.