หนึ่งในเป้าหมายหลักที่โครงการที่ใช้บล็อคเชนมุ่งหวังที่จะบรรลุคือการตรวจสอบข้อมูล สำหรับตัวอย่างสด คุณสามารถดูข้อมูลประจำตัวดิจิทัล พื้นที่จัดเก็บและการตรวจสอบเอกสารออนไลน์ได้ โดยแท้จริงแล้ว กรณีใดๆ เหล่านี้จำเป็นต้องมีการตรวจสอบผู้เริ่มดำเนินการ/ธุรกรรมเพื่อยืนยันบุคคลหรือนิติบุคคล ตัวอย่างเช่น หากบุคคลนั้นมีเอกสารประจำตัวในรูปแบบดิจิทัล การรับรองความเป็นเจ้าของจึงเป็นสิ่งสำคัญ ดังนั้นจึงเป็นตัวอย่างที่ดีของปัญหาการตรวจสอบข้อมูล เรามาทบทวนรูปแบบที่ง่ายที่สุดของโซลูชันกัน — ลายเซ็นดิจิทัล ซึ่งการทดสอบเป็นหนึ่งในจุดสำคัญในระหว่างการพัฒนาสัญญาอัจฉริยะ
วิธีการนั้นง่าย:
1) ระบบสร้างข้อความตามกฎที่ทุกคนรู้จัก
2) ผู้ลงนามได้รับข้อความและเพิ่มชุดสัญลักษณ์เฉพาะ — ลายเซ็นดิจิทัล รหัสที่สร้างจากข้อความด้วยคีย์ส่วนตัว
3) ขณะนี้ลายเซ็นที่สร้างขึ้นจะถูกส่งไปยังสัญญา ซึ่งจะถูกสลายเพื่อดึงที่อยู่ของผู้ลงนาม
Solidity นำเสนออัลกอริธึม ECDSA สำหรับการสร้างลายเซ็นและการแยกส่วนเพิ่มเติม เราไม่จำเป็นต้องเจาะลึกลงไปในอัลกอริทึม (คุณสามารถค้นหาข้อมูลที่จำเป็นได้ ในแหล่งที่เหมาะสม). สิ่งที่เราจำเป็นต้องรู้ก็คือ ECDSA เป็นตัวอย่างของการเข้ารหัสแบบอสมมาตร โดยที่ผู้ใช้รายแรกสร้างลายเซ็นด้วยคีย์ส่วนตัวของตน และผู้ใช้รายที่สองใช้อัลกอริธึมมาตรฐานเพื่อดึงข้อมูลคีย์สาธารณะของผู้ลงนาม จึงสามารถตรวจสอบที่มาของลายเซ็นได้ ให้เรามุ่งเน้นไปที่ส่วนที่ใช้งานได้จริงแทน — การใช้และการทดสอบลายเซ็น
ก่อนอื่น เราต้องรับรู้ถึงปัญหาก่อน ตัวอย่างเช่น สัญญาจำเป็นต้องดำเนินการบางอย่าง เช่น เก็บที่อยู่ของผู้โทร แม้ว่าสัญญาควรจัดเก็บข้อมูลเฉพาะเมื่อมีการยืนยันผู้โทรแล้ว แต่เราต้องแน่ใจว่าไม่มีใครสามารถใช้ที่อยู่ของตนโดยไม่ได้รับอนุญาต เพื่อเรียกข้อมูลผู้โทรที่แท้จริง เราจำเป็นต้องสร้างข้อความ ลงนาม และแยกย่อยภายในสัญญา
คุณสามารถค้นหา โซลูชันมาตรฐานในเอกสาร Solidity (ตัวอย่างเช่น, ใน 0.8.4 — เวอร์ชันเสถียรล่าสุด ณ ขณะของบทความ) เอกสารเสนอสัญญาให้เรา ซึ่งจำเป็นต้องมีฟังก์ชันในตัวต่อไปนี้: การสร้างข้อความ การแยกลายเซ็น และโค้ดแอสเซมบลีเพื่อดึงข้อมูลผู้ลงนาม ตัวอย่างนี้แสดงวิธีการที่จำเป็นทั้งหมดและค่อนข้างตรงไปตรงมา แม้ว่าจะมีข้อเสียอยู่ XNUMX ประการ: ไม่มีความเป็นสากล และไม่มีตัวอย่างที่ดีของการทดสอบโซลูชัน นั่นเป็นเหตุผลที่ฉันจัดเตรียมโค้ดเวอร์ชันของฉันและ (เป้าหมายที่แท้จริง) — กลยุทธ์การทดสอบของสัญญา
ใช้ได้เลย ไลบรารี OpenZeppelin มาตรฐาน สำหรับการปฏิบัติงานของ ECDSA แต่คุณจะพบปัญหาเดิมอีกครั้ง — ขาดความยืดหยุ่นและวิธีการทดสอบ มาดูตัวอย่างตรรกะตามลายเซ็นของฉันกันดีกว่า คุณสามารถค้นหาความสมบูรณ์ได้ ตัวอย่างการทำงานใน GitHub ของฉันแต่มีไม่กี่ที่ที่ผมอยากจะแสดงแบบเต็มๆ
ก่อนอื่นเราจะเตรียมข้อความ อย่างที่คุณเห็น มันถูกสร้างขึ้นจากที่อยู่กระเป๋าเงินที่ถูกแพ็คและแฮชสองแห่ง:
โค้ดสำคัญชิ้นที่สองคือการแฮชข้อความพร้อมกับข้อความ Ethereum มาตรฐาน:
แสดงว่าข้อความถูกส่งภายในเครือข่าย Ethereum และมีความยาว 32 ไบต์ ซึ่งไม่ใช่ตัวเลขสุ่ม หลังจากการดำเนินการก่อนหน้านี้ เรามีแฮชซึ่งมีความยาว 32 ไบต์ จำเป็นต้องมีฟังก์ชันแฮชเพิ่มเติมในรูปแบบดังกล่าว และเราจะหารือเกี่ยวกับเหตุผลในภายหลัง
ส่วนโค้ดอื่นๆ ค่อนข้างเป็นมาตรฐาน ฟังก์ชั่นการแยกลายเซ็นมีดังนี้:
และนี่คือฟังก์ชันในการดึงข้อมูลผู้ลงนาม:
สำหรับอินเทอร์เฟซภายนอก เราจะใช้ฟังก์ชันแบบกำหนดเอง ซึ่งรับลายเซ็นและอาร์กิวเมนต์ที่จำเป็น ตรวจสอบว่าผู้ใช้ได้ลงทะเบียนแล้ว สร้างข้อความ และตรวจสอบลายเซ็น:
ขั้นแรก เราจะเลียนแบบข้อความที่ต้องลงนาม เราจะใช้ ethers.js ห้องสมุดซึ่งก็คือ (ร่วมกับ web3) ห้องสมุดที่มีคนใช้และสะดวกที่สุด เนื่องจากเป็นห้องสมุดโอเพ่นซอร์ส คุณจึงมีอิสระในการสำรวจ รหัสและเอกสารของมัน. นอกจากนี้ ไลบรารีนี้ยังให้อินเทอร์เฟซที่สมบูรณ์แบบสำหรับการสร้างข้อความต่อไปนี้:
ข้อเสียอย่างหนึ่งของทั้งสองอย่าง web3 และ อีเทอร์ ไลบรารีคือไม่มีฟังก์ชันทั้งหมดสำหรับสภาพแวดล้อม Ganache ในพื้นที่ เนื่องจากไลบรารีทั้งสองมีเป้าหมายที่จะทำงานกับโหนด Ethererum เต็มรูปแบบ อย่างไรก็ตามยังมีแนวทางให้ทดสอบในท้องถิ่นโดยใช้ ฟังก์ชั่นบัญชี web3. แม้ว่าคุณจะต้องสร้างบัญชีเพิ่มเติม ซึ่งจะใช้ฟังก์ชันนักร้องและให้การเชื่อมต่อกับผู้ให้บริการ web3 ปัจจุบัน:
ตอนนี้เราได้สร้างข้อความและลงนามแล้ว แต่นั่นไม่ใช่ทั้งหมด มีบางสิ่งที่เหลืออยู่ที่จะพูดคุยเกี่ยวกับ ไลบรารีทั้งสอง (web3 และ ethers) ภายใต้ประทุนให้การแฮชข้อความเพิ่มเติมก่อนการสร้างลายเซ็น นอกจากนี้ ข้อความไม่เพียงแต่ถูกแฮช แต่ยังรวมเข้ากับข้อความ Ethereum มาตรฐานที่เราเห็นก่อนหน้านี้:
และนั่นคือเหตุผลที่เราเพิ่มวิธีการเพิ่มเติมให้กับสัญญา ดังนั้น หากคุณต้องการใช้ข้อความที่กำหนดเอง ข้ามการแฮชเพิ่มเติม ฯลฯ คุณต้องสร้างฟังก์ชันการเซ็นชื่อเวอร์ชันที่กำหนดเอง เราได้กล่าวถึงเหตุผลข้างต้นแล้ว - ไลบรารีมาตรฐานทั้งสองใช้แนวทางทั่วไปในการลงนามข้อความ ซึ่งสามารถเปลี่ยนแปลงได้โดยการแทนที่ฟังก์ชันการทำงานเท่านั้น
ในขั้นตอนสุดท้าย ให้ทำการทดสอบและตรวจดูว่าทำงานถูกต้องหรือไม่:
เราได้ทดสอบการสร้างลายเซ็น ข้อความที่สร้างขึ้น การอนุมัติลายเซ็น และการปฏิเสธ ดังนั้นจึงเป็นชุดการทดสอบที่สมบูรณ์สำหรับฟังก์ชันการตรวจสอบ
- ลงชื่อเข้าใช้
- การกระทำ
- เพิ่มเติม
- ขั้นตอนวิธี
- ทั้งหมด
- ข้อโต้แย้ง
- บทความ
- จริง
- บิต
- กรณี
- การตรวจสอบ
- รหัส
- สัญญา
- การอ่านรหัส
- ปัจจุบัน
- ข้อมูล
- พัฒนาการ
- ดิจิตอล
- ตนดิจิตอล
- เอกสาร
- สิ่งแวดล้อม
- ethereum
- เครือข่าย ethereum
- ใบหน้า
- ชื่อจริง
- ความยืดหยุ่น
- โฟกัส
- ฟอร์ม
- ฟรี
- เต็ม
- ฟังก์ชัน
- ดี
- กัญชา
- hashing
- HTTPS
- ia
- เอกลักษณ์
- ข้อมูล
- IP
- IT
- คีย์
- ล่าสุด
- ห้องสมุด
- ในประเทศ
- กลาง
- เครือข่าย
- โหนด
- เสนอ
- เสนอ
- ออนไลน์
- เปิด
- โอเพนซอร์ส
- การดำเนินการ
- ส่วนตัว
- คีย์ส่วนตัว
- โครงการ
- สาธารณะ
- คีย์สาธารณะ
- ทบทวน
- วิ่ง
- ชุด
- ง่าย
- So
- ความแข็งแรง
- แยก
- การเก็บรักษา
- จัดเก็บ
- กลยุทธ์
- ระบบ
- ทดสอบ
- การทดสอบ
- การทดสอบ
- ที่มา
- us
- การตรวจสอบ
- กระเป๋าสตางค์
- วิกิพีเดีย
- ภายใน
- งาน
- โรงงาน