Bir did:solidus Kaydettiğinizde Gerçekte Ne Oluyor

Özel anahtarınız tarayıcınızda üretiliyor, kayıt işlemini orada imzalıyor ve bize hiçbir zaman gönderilmiyor. Sunucumuz, sizin çoktan imzaladığınız bir işlemi aktarıyor.

O ilk iddia genelde yalnızca öne sürülen türdendir, dolayısıyla bu sayfanın geri kalanı onu nasıl kontrol edebileceğinizdir, sunucumuzu hiç kullanmamak dahil.

Sıra

Tarayıcı bir Ed25519 anahtar çifti üretiyor. Özel anahtar tarayıcı depolamasına gidiyor.
Tarayıcı bir DidCreate işlemi kuruyor ve onu yerel olarak imzalıyor.
İmzalanmış işlemi, yalnızca imzalanmış işlemi, /v1/onboarding/register adresine POST ediyor.
Arka ucumuz şeklini kontrol ediyor: yükün 32 baytlık bir açık anahtar ve 32 baytlık bir gönderen anahtarı taşıması gerekiyor, yoksa bir 400 alıyorsunuz.
Arka ucumuz onu zincire aktarıyor ve makbuzu bekliyor, 12 saniyelik bir tavanla.
Zincir karar veriyor. Arka ucumuzun kendi yorumu bunu açıkça söylüyor: "The chain enforces the full invariant set; this code just rejects obvious malformed input before going over the wire."
Başarı hâlinde bir satır saklıyoruz: tanımlayıcınız, açık anahtarınız ve bir görünen ad.

Zincirin gerçekte neyi dayattığı

Bir şartnameden alınmak yerine mutabakat kaynağında okundu:

Tamamı sıfır bir açık anahtar geri çevriliyor.
Açık anahtardan türetilen adres, işlemin gönderen adresine eşit olmak zorunda. Değilse, işlem bir uyuşmazlık hatasıyla başarısız oluyor. Kaydı kendi kendini belgeleyen yapan şey budur: tutmadığınız bir anahtarı kaydedemiyorsunuz, çünkü adresi üreten şey onu tutmanızdır.
Zaten belgesi olan bir tanımlayıcı yeniden oluşturulamıyor.

O üçüncü taraf kanıtı özelliği bütün mesele. Arka ucumuz kötü niyetli olabilirdi ve yine de kontrol etmediği bir anahtarı kaydedemezdi, çünkü zincir türetmeyi kontrol ediyor ve arka ucumuzun bir oyu yok.

Sunucumuzu kullanmak zorunda değilsiniz, ve buna inanmanız yerine doğrulamanızı tercih ederiz

Zincirin işlem gönderme yöntemi açıktır. 2026-07-31'de, cevabı anlamlı kılan kontrollerle sondalandı:

$ curl -s -X POST https://rpc.solidus.network -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","method":"solidus_sendTransaction","params":[],"id":1}'
  → {"error":{"code":-32602,"message":"Invalid params","data":"No more params"}}   ← METHOD EXISTS

$ ... "method":"solidus_zzzNotAMethod" ...
  → {"error":{"code":-32601,"message":"Method not found"}}                          ← control

Bir parametre hatası ile bir eksik yöntem hatası farklı cevaplardır ve ikincisi, uydurduğumuz bir adın döndürdüğü şeydir. Dolayısıyla ilki gerçektir: kendi DidCreate'inizi arka ucumuz yolda hiç olmadan kurup gönderebilirsiniz.

Tanımlayıcı oluşturma için bir dar boğaz değiliz ve bu tek bir komutta kontrol edilebilir.

Bunun sınırı, çünkü tatmin edici tek bir curl hikâyenin tamamı değil

Onu cevaplayan düğüm bizim. Bu ağda bir düğüm işletmecisi var, biziz, ve ikinci bir açık uç nokta bilmiyoruz. "Göndermek için izinsiz" ile "Solidus'tan bağımsız" aynı cümle değildir. Onu çalıştırmayı bıraksaydık, yöntemin herkesin işlemini kabul ediyor olması önemli olmayı bırakırdı.

Bunu tutmanın doğru yolu: tasarım bize güvenmeyi gerektirmiyor ve dağıtım şu anda gerektiriyor. Bunlar farklı problemlerdir ve yalnızca biri çözülmüştür.

Kayıt ücretsizdir ve zincirdeki hiçbir şey onu hız sınırlamıyor

DidCreate ücretten muaftır. Tanımlayıcı güncellemeleri, devre dışı bırakma, kurtarma ve kimlik bilgisi verme ve iptali de öyle. Yapısal bir sebebi var: bir DID'in demirlediği adres kuruluşu gereği değerden bağımsızdır ve bakiye tutamıyor, dolayısıyla ondan ücret almak, tam olarak buna ihtiyacı olan taraf için kaydı imkânsız kılardı.

Sonuç kendi kaynak yorumumuzda belirtiliyor ve onu atlamayacağız: bu ücretsiz işlemler için spam denetimi aktarıcıda yaşıyor, artı açıkça ana ağ öncesi olan ve inşa edilmemiş sponsorlu bir ücret düzeneğinde. Gönderme yöntemi açık olduğu için, aktarıcı atlanabilir.

İstemci tarafı anahtarların bedeli, bir bedel olarak belirtilmiş

Anahtarın sunucumuza hiç ulaşmaması gerçekten iyidir. Aynı zamanda şu anlama geliyor:

Tarayıcı depolamasında yaşıyor, ki o köken üzerinde çalışan herhangi bir betik tarafından okunabilir. Alan adımızdaki bir siteler arası betik açığı onu okuyor. Bu kuramsal değil gerçek bir maruziyettir ve tarayıcıda tutulan anahtarların standart takasıdır: onun etrafından satmak yerine adlandırıyoruz.
Onu kaybetmek tanımlayıcıyı kaybetmektir. Bizim tarafımızda bir sıfırlama yok çünkü bizim tarafımızda sıfırlanacak bir şey yok.
Site verisini temizlemek anahtarı temizliyor. İnsanlar bunu kazara yapıyor.

O takası, sonradan keşfetmenizdense yapmadan önce anlamanızı tercih ederiz.

Neyi sakladığımız

Tanımlayıcınızı, açık anahtarınızı ve bir görünen adı. Tanımlayıcı sütunu benzersizdir, dolayısıyla bir hesap bir tanımlayıcı tutuyor, ki bu aynı zamanda o tanımlayıcının bu üründeki her şeyin asıldığı tanıtıcı olduğu anlamına geliyor. Bunun mahremiyet için ne ifade ettiği DID'inizi herkes arayabilir mi sayfasındadır ve oradaki cevap evettir.

Kendiniz neyi kontrol edemezsiniz

Kayıt uç noktası bir kaydolma akışının parçasıdır, dolayısıyla uçtan uca yol, bir yabancının hesap oluşturmadan çalıştırabileceği bir şey değil. En çok önemli olan iki iddia yine de kontrol edilebilir: gönderme yönteminin varlığı, yukarıda, ve dayatma kurallarının kaynağı, ki açık koddur. Sayfanın geri kalanı kod okuması kanıtıdır ve onu öyle notlandırıyoruz.

İçerik planımız bu sayfayı /create-a-did olarak adlandırıyor. O rota canlı değil: 404 döndürüyor, kasıtlı olarak sahte bir yol da öyle.