Blockchain tabanlı projelerin ulaşmayı amaçladığı ana hedeflerden biri verilerin doğrulanmasıdır. Canlı örnekler için dijital kimlik ve çevrimiçi belge saklama ve kontrollerine bakabilirsiniz. Gerçekten de, bu durumlardan herhangi biri, kişiyi veya kuruluşu doğrulamak için eylem/işlem başlatan doğrulamasını gerektirir. Örneğin, kişinin kimlik belgesinin dijital formu varsa, sahipliğini sağlamak çok önemli hale gelir. Bu nedenle, veri doğrulanabilirliği sorununun mükemmel bir örneğidir. Çözümün en basit biçimini gözden geçirelim - akıllı sözleşme geliştirme sırasında testi çok önemli noktalardan biri olan dijital imza.
Yaklaşım basit:
1) sistem herkes tarafından bilinen kurallara göre bir mesaj üretir
2) imzalayan mesajı alır ve belirli bir sembol seti ekler – dijital imza, mesajdan özel bir anahtarla oluşturulan kod
3) oluşturulan imza şimdi, imzalayanın adresini almak için ayrıştırıldığı sözleşmeye gönderilir.
Solidity, imza oluşturma ve daha fazla ayrıştırma için size ECDSA algoritmasını sunar. Algoritmanın kendisini derinlemesine incelememize gerek yok (gerekli bilgileri bulabilirsiniz uygun kaynaklarda). Tek bilmemiz gereken, ECDSA'nın, ilk kullanıcının kendi özel anahtarıyla bir imza oluşturduğu ve ikinci kullanıcının imzalayanın genel anahtarını almak için standart bir algoritma uyguladığı asimetrik şifrelemenin bir örneği olduğudur. Böylece imzanın kaynağını doğrulayabilir. Bunun yerine, pratik kısma odaklanalım - imza kullanımı ve test.
Her şeyden önce, bir sorunu tanımamız gerekiyor. Örneğin, sözleşmenin bazı eylemleri gerçekleştirmesi gerekiyor, diyelim ki arayanın adresini kaydedin. Sözleşme, yalnızca arayan doğrulanırsa depolamayı gerçekleştirse de, kimsenin adresini izinsiz kullanamayacağından emin olmamız gerekir. Gerçek arayanı almak için bir mesaj oluşturmamız, imzalamamız ve sözleşme içinde ayrıştırmamız gerekiyor.
Sen bulabilirsiniz Solidity belgelerinde standart çözüm (Örneğin, 0.8.4 içinde — makale anındaki en son kararlı sürüm). Dokümanlar bize şu yerleşik işlevselliğe ihtiyaç duyan sözleşmeyi sunar: mesaj oluşturma, imza bölme ve imzalayanı almak için derleme kodu. Örnek, gerekli tüm yöntemleri gösterir ve iki dezavantajı olmasına rağmen oldukça basittir: evrensellikten yoksundur ve iyi bir çözüm testi örneği yoktur. Bu yüzden kodumun sürümünü ve (gerçek hedef) - sözleşmenin test stratejisini sağlıyorum.
tabiki kullanabilirsin standart OpenZeppelin kitaplığı ECDSA operasyonları için, ancak yine aynı sorunlarla karşılaşacaksınız - esneklik eksikliği ve test yaklaşımları. Öyleyse, imza tabanlı mantık örneğime dalalım. komple bulabilirsiniz GitHub'ımda çalışan örnek, ancak tam olarak göstermek istediğim birkaç yer var.
Her şeyden önce, mesajı hazırlayacağız. Gördüğünüz gibi, iki paketlenmiş ve karma cüzdan adresinden oluşur:
İkinci önemli kod parçası, mesajı standart Ethereum mesajıyla birlikte hash etmektir:
Mesajın Ethereum ağı içinde gönderildiğini ve rastgele bir sayı olmayan 32 bayt uzunluğunda olduğunu gösterir. Önceki işlemlerden sonra, 32 bayt uzunluğunda bir hash elde ederiz. Bu şekilde ek hash fonksiyonuna sahip olmak esastır ve bunun gerekçesini biraz sonra tartışacağız.
Diğer kod parçaları oldukça standarttır. İmzayı bölme işlevi aşağıdaki gibidir:
ve imzalayanı alma işlevi:
Harici arayüz için, imzayı ve gerekli argümanları alan, kullanıcının zaten kayıtlı olup olmadığını kontrol eden, mesajı oluşturan ve imzayı doğrulayan özel işlevi kullanacağız:
İlk olarak, imzalanması gereken mesajı taklit edeceğiz. Kullanacağız eterler.js olan kütüphane (birlikte web3) en çok kullanılan ve kullanışlı kütüphane. Açık kaynaklı bir kütüphane olduğu için keşfetmekte özgürsünüz kodu ve belgeleri. Ayrıca, bu kitaplık bize aşağıdaki mesajı oluşturmak için mükemmel bir arayüz sağlar:
İkisinin de eksilerinden biri web3 ve eterler kütüphaneler, her iki kütüphanenin de tam Ethererum düğümleriyle çalışması hedeflendiğinden, yerel Ganache ortamı için tüm işlevlere sahip olmamalarıdır. Bununla birlikte, yerel test için bir yaklaşım vardır. web3 hesabı işlevi. Şarkıcı işlevini uygulayacak ve mevcut web3 sağlayıcısına bağlantı sağlayacak ek bir hesap oluşturmanız gerekmesine rağmen:
Böylece, şimdi oluşturulan ve imzalanan mesajımız var. Ancak, hepsi bu değil; konuşulacak birkaç şey kaldı. Başlık altındaki her iki kitaplık (web3 ve eterler), imza oluşturmadan önce mesajın ek hash edilmesini sağlar. Ayrıca, mesaj yalnızca karma değil, daha önce gördüğümüz standart Ethereum mesajıyla birleştirilir:
İşte bu yüzden sözleşmeye ek yöntemi ekledik. Bu nedenle, özel iletiler kullanmak, ek karma oluşturmayı vb. atlamak istiyorsanız, imzalama işlevinin özel bir sürümünü oluşturmanız gerekir. Yukarıdaki nedeni tartıştık - her iki standart kitaplık da, yalnızca işlevselliği geçersiz kılarak değiştirilebilen mesajı imzalamak için tipik yaklaşımı uygular.
Son adım olarak testi çalıştıralım ve doğru çalışıp çalışmadığını kontrol edelim:
İmza oluşturmayı, oluşturulan mesajı, imza onayını ve reddini test ettik. Bu nedenle, doğrulama işlevi için oldukça eksiksiz bir test setidir.
- Hesap
- Action
- Ek
- algoritma
- Türkiye
- argümanlar
- göre
- Otantik
- Bit
- durumlarda
- Çekler
- kod
- sözleşme
- kriptografi
- akım
- veri
- gelişme
- dijital
- dijital kimlik
- evraklar
- çevre
- Ethereum
- ethereum ağı
- Yüz
- Ad
- Esneklik
- odak
- Airdrop Formu
- Ücretsiz
- tam
- işlev
- Tercih Etmenizin
- esrar
- karma
- HTTPS
- ia
- Kimlik
- bilgi
- IP
- IT
- anahtar
- son
- Kütüphane
- yerel
- orta
- ağ
- düğümler
- teklif
- Teklifler
- Online
- açık
- açık kaynak
- Operasyon
- özel
- özel Anahtar
- Projeler
- halka açık
- kamu Anahtarı
- yorum
- koşmak
- set
- Basit
- So
- katılık
- bölmek
- hafızası
- mağaza
- Stratejileri
- sistem
- test
- Test yapmak
- testleri
- Kaynak
- us
- Doğrulama
- Cüzdan
- Vikipedi
- içinde
- İş
- çalışır