ชื่อเดิม: "A&T View: การตรวจสอบแทร็ก DID ที่ละเอียดที่สุดในเครือข่ายทั้งหมด + คำถามสามข้อเกี่ยวกับวิญญาณ DID"

ผู้เขียน: Lin Chuan นักวิเคราะห์อาวุโสของ A&T Capital

สรุป

สรุป

• โดยทั่วไปแล้ว DID เป็นคำย่อของ "Decentralized Identity" (Decentralized Identity) เป็นข้อมูลประจำตัวดิจิทัลที่ไม่มีการรับประกันขั้นสุดท้ายจากองค์กรส่วนกลาง เป็นการขยายและขยายแนวคิดของ "ภาพเหมือนผู้ใช้" ใน Web2 ใน Web3

• แทร็กที่เกี่ยวข้องกับ DID นั้นแบ่งออกเป็นสามเลเยอร์เป็นหลัก: สถานการณ์แอปพลิเคชัน ข้อมูลระบุตัวตน และข้อมูลประจำตัว ชั้นข้อมูลรับรองเป็นส่วนประกอบของ DID ชั้นข้อมูลประจำตัวเป็นรูปแบบเฉพาะของ DID และชั้นสถานการณ์จำลองแอปพลิเคชันเป็นศูนย์รวมค่าของ DID

• รูปแบบสุดท้ายของการพัฒนา DID อาจเป็นได้ว่าผู้ใช้แต่ละคนมีเอกลักษณ์เฉพาะทั่วทั้งเครือข่ายและตัวตนบางส่วนในสถานการณ์ที่แบ่งย่อยหลายส่วน ผู้ใช้จดจำและระบุ DID ผ่านชื่อโดเมน จัดการ DID และโต้ตอบกับโครงการแอปพลิเคชันผ่านกระเป๋าเงิน และรวมข้อมูลประจำตัวที่แตกต่างกันและข้อมูลประจำตัวบางส่วนบนหลายเชนผ่านโปรโตคอลต่างๆ ในการรวมกระเป๋าเงิน

• ขณะนี้ DID ไม่ใช่ความต้องการโดยตรงของผู้ใช้ แต่เป็นความต้องการของฝ่ายโครงการสถานการณ์จำลองแอปพลิเคชันมากกว่า

• การพัฒนา DID ยังอยู่ในช่วงเริ่มต้นและการทำซ้ำค่อนข้างช้า จนถึงตอนนี้ ไม่มีระบบ DID ใดที่สะสมเอฟเฟกต์เครือข่ายบางอย่าง สาเหตุหลักมาจากความยากลำบากในการพัฒนาโครงการแอปพลิเคชันที่ไม่ใช่ทางการเงินของ Web3 ในปัจจุบัน

• ตรรกะโดยรวมของการลงทุนระดับแรก DID: เริ่มจากผู้ใช้ แอปพลิเคชันมาก่อนข้อตกลง

คำนำ: DID แนวคิดที่ใช้กันอย่างแพร่หลายและถูกละเมิด

DID เป็นแนวคิดยอดนิยมในฟิลด์ Web3 บน Twitter มี Twitter Space ที่พูดถึง DID เกือบทุกสัปดาห์ ในเซสชันการแชร์ Web3 ออฟไลน์ต่างๆ DID ก็เป็นหนึ่งในหัวข้อร้อนที่ยั่งยืน ในสำรับทางการเงินของโครงการ ไม่ว่าจะเป็นโซเชียล, GameFi, DeFi , NFT และโครงการแอปพลิเคชันอื่นๆ หรือโครงการอินฟาเรด/มิดเดิลแวร์ เช่น กระเป๋าเงิน ชื่อโดเมน และแม้แต่เครือข่ายสาธารณะ อาจเพิ่ม DID ลงในเรื่องเล่าของพวกเขา

อย่างไรก็ตาม ความนิยมสูงดังกล่าวย่อมทำให้คำว่า DID ถูกใช้อย่างกว้างขวางและแม้แต่ในทางที่ผิด:

• ในตอนต้น ชื่อเต็มของ DID คือ "Decentralized Identifiers" ซึ่งแปลตามตัวอักษรว่า "Decentralized Identifiers" เป็นชุดของมาตรฐานที่นำโดย World Wide Web Consortium (W3C) ซึ่งเป็นหน่วยงานมาตรฐานด้านเทคโนโลยีอินเทอร์เน็ตระหว่างประเทศที่ทรงอิทธิพลที่สุด เนื่องจากข้อกังวลเกี่ยวกับระบบระบุตัวตนแบบรวมศูนย์ของ Web2 แนวคิดของ DID ไม่ได้เกี่ยวข้องโดยตรงกับ blockchain/Web3 ในตอนเริ่มต้น แต่ถ้าคุณค้นหา "DID" โดยตรง คุณยังคงเห็นได้ว่า DID ที่กล่าวถึงในหลายๆ บทความคือมาตรฐานเฉพาะนี้

• ในการสื่อสาร Web3 ในปัจจุบัน DID มักถูกมองว่าเป็นตัวย่อของ "Decentralized Identity" ซึ่งหมายถึง "เอกลักษณ์ที่กระจายอำนาจ (ดิจิทัล)" อย่างไรก็ตาม เอกลักษณ์แบบกระจายศูนย์เองก็เป็นคำศัพท์ที่ขาดคำจำกัดความที่ชัดเจน แม้ว่าทุกคนจะเข้าใจความหมายทั่วไปของมันได้อย่างรวดเร็ว แต่มันอาจจะหมายถึงสิ่งต่าง ๆ ในสถานการณ์ต่าง ๆ และในโลกของ Web3 ดูเหมือนว่าอะไร ๆ ก็สามารถเกี่ยวข้องกันได้ ไปมัน ด้วยเหตุนี้จึงมีความสับสนทางแนวคิดอย่างมากในการอภิปรายเรื่อง DID ในปัจจุบัน

DID ที่กล่าวถึงในบทความนี้จะใช้แนวคิดหลังของ "ข้อมูลประจำตัวดิจิทัลแบบกระจายอำนาจ" และจะใช้ DID เพื่ออ้างถึงมาตรฐานตัวระบุแบบกระจายศูนย์ของ W3C เพื่อหลีกเลี่ยงความสับสน

บทความนี้แบ่งออกเป็นส่วนแรกและส่วนถัดไป ในส่วนแรก ผู้เขียนจะแบ่งชั้นสถานการณ์ของแอปพลิเคชัน ชั้นเอกลักษณ์ และชั้นข้อมูล และทำการทบทวนการติดตาม DID อย่างเป็นระบบเพื่อช่วยให้ผู้อ่านเข้าใจความแตกต่างและความเชื่อมโยงระหว่างแนวคิดต่างๆ ในส่วนที่สอง ผู้เขียนจะ อธิบายมุมมองเชิงอัตวิสัยบางส่วนเกี่ยวกับการพัฒนาเพลง DID ในอนาคตและการลงทุนในช่วงแรก เพื่อให้ผู้อ่านได้คิดและสื่อสาร

ก่อนหน้านี้: การตีความแบบพาโนรามาของแทร็ก Decentralized Identity (DID)

ใน Web2 ข้อมูลประจำตัวดิจิทัลจะอยู่ที่แพลตฟอร์ม และผลิตภัณฑ์ต่างๆ ในกลุ่มเดียวกันจะเชื่อมต่อกันผ่านระบบบัญชี ตัวอย่างเช่น กล่องจดหมาย เกม การเงิน ฯลฯ ของ Tencent สามารถใช้บัญชีเดียวกันได้ Google, Facebook และบริษัทอินเทอร์เน็ตชั้นนำอื่น ๆ ก็มีระบบบัญชีของตนเองเช่นกัน แม้ว่าระบบระบุตัวตนนี้จะสะดวกในการสร้าง แต่ข้อเสียของมันก็เป็นที่ทราบกันดี: บัญชีระหว่างแพลตฟอร์มไม่สามารถทำงานร่วมกันได้ และผู้ใช้ไม่มีทางควบคุมข้อมูลประจำตัวของตนเองได้

ใน Web3 ปัจจุบัน การโต้ตอบของผู้ใช้จะขึ้นอยู่กับที่อยู่กระเป๋าเงินเป็นหลัก ดังนั้นชุดของกิจกรรมรอบๆ ที่อยู่จึงถือเป็นตัวตนดิจิทัลดั้งเดิมที่สุดของ Web3 แต่ค่าใช้จ่ายในการสร้างที่อยู่ใหม่แทบจะไม่สำคัญเลย และน้อยคนนักที่จะผูกมัดตัวเองกับที่อยู่ สิ่งนี้นำไปสู่ความจริงที่ว่าผู้ใช้สามารถละทิ้ง "ตัวตน" ที่แสดงโดยที่อยู่ได้ตลอดเวลา และยังสามารถสร้าง "ตัวตน" ของที่อยู่จำนวนมากได้โดยไม่มีค่าใช้จ่าย ซึ่งจะจำกัดสถานการณ์การใช้งานของตัวตนดิจิทัลนี้ .

ปัญหาที่ DID หวังว่าจะแก้ไขคือการสร้างภาพตัวตนของบุคคลในโลกดิจิทัลแบบกระจายอำนาจ

1. สถานการณ์การใช้งานของ DID: หากเรามีชุด DID ที่ครบกำหนดแล้ว...

DID เป็นแนวคิดเชิงนามธรรม เพื่อให้เข้าใจโดยสัญชาตญาณได้ดีขึ้น ให้เราป้องกันรายละเอียดของวิธีนำ DID ไปใช้ โดยเริ่มจากสถานการณ์การใช้งาน: หากมีชุด DID ที่ครบกำหนดแล้วในโลกของ Web3 สิ่งที่สามารถ มันทำ?

ผู้เขียนแบ่งการเล่าเรื่องของ DID อย่างคร่าว ๆ ในเลเยอร์สถานการณ์การใช้งานออกเป็นสองประเภท: Reputation (ชื่อเสียง) และ Relationship (ความสัมพันธ์)

วิธีหลักในการแยกแยะความแตกต่างคือสมมติว่าหากคุณกำลังจะละทิ้ง "ตัวตนดิจิทัล" ที่มีอยู่ คุณสามารถสร้างตัวตนใหม่ที่สามารถเป็นตัวแทนของคุณในระยะเวลาอันสั้นได้หรือไม่

ถ้าเป็นแบบแรก จะเป็นคลาส Reputation ถ้าเป็นแบบหลัง จะเป็นคลาส Relationship

1.1 ชื่อเสียง: ชื่อเสียง/ประวัติย่อ/สถานะทางสังคม

สถานการณ์การใช้งานประเภทนี้มุ่งเน้นไปที่การประเมินและจำแนกผู้ใช้โดยลดความซับซ้อนของข้อมูลระบุตัวตนดิจิทัลลงในป้ายกำกับที่ชัดเจนและเชื่อถือได้ เพื่อให้ได้ผลการคัดกรองที่รวดเร็ว ต่อไปนี้เป็นตัวอย่างที่เฉพาะเจาะจงสามตัวอย่าง: การให้สินเชื่อ การหางาน การเข้าสังคมกับคนแปลกหน้า:

• สินเชื่อเครดิต Web3 โดยหวังว่าจะให้ "คะแนนเครดิต" กับที่อยู่บัญชีของผู้ใช้ เพื่อคำนวณจำนวนเงินที่สามารถลดหรือยกเว้นได้ในสินเชื่อเครดิต คะแนนเครดิตประเภทนี้สามารถทำได้ผ่านการพิสูจน์ตัวตน/สินทรัพย์นอกเครือข่าย หรือสามารถใช้ร่วมกับการวิเคราะห์บันทึกการดำเนินงานที่ผ่านมาของที่อยู่ออนไลน์ของผู้ใช้

• สำหรับการหางานและการสรรหาบุคลากรของ Web3 เราหวังว่าจะสามารถสร้างประวัติย่อของผู้ใช้บนห่วงโซ่ได้ เพื่อให้ผู้ใช้สามารถพิสูจน์ความสามารถของตนได้อย่างรวดเร็วต่อกลุ่มโครงการ Web3/DAO/ชุมชน ฯลฯ และลดความขัดแย้งของข้อมูลในงาน Web3 กระบวนการล่าและสรรหา การรับรองประสบการณ์การทำงานและความสามารถ Web3 ในเรซูเม่สามารถทำได้ผ่านการวิเคราะห์ที่อยู่แบบเครือข่าย ลายเซ็นของที่อยู่กระเป๋าเงินแบบหลายลายเซ็นของเจ้าของเดิม และการรับรองอีเมลของบริษัท Web2

• Web3 Stranger Social (รวมถึงสังคมรักต่างเพศ สังคมที่สนใจ ฯลฯ) โดยหวังว่าจะสร้างคำอธิบายแท็กสำหรับผู้ใช้ได้อย่างรวดเร็ว คำอธิบายของป้ายกำกับประเภทนี้อาจขึ้นอยู่กับการถือครอง NFT ตัวอย่างเช่น ผู้ถือ BAYC สามารถระบุได้ว่า "รวย" และผู้ถือ NFT ที่มีความสนใจหลากหลายและชุมชนก็สามารถระบุได้เช่นกัน ผู้ใช้สามารถรวมแท็กเหล่านี้และวางไว้บนหน้าแรกโซเชียลเพื่อแสดง นอกจากนี้ ผู้ใช้ยังสามารถกรองอ็อบเจ็กต์ที่พวกเขาต้องการโซเชียลด้วยตามแท็กเหล่านี้ได้อย่างรวดเร็ว และมีความเข้าใจเบื้องต้นเกี่ยวกับความสนใจและความชอบของพวกเขา

1.2 ความสัมพันธ์: การเล่าเรื่องเกี่ยวกับแอปพลิเคชันเชิงสัมพันธ์ของ DID

สถานการณ์แอปพลิเคชันประเภทนี้มุ่งเน้นไปที่การวิเคราะห์แอปพลิเคชันที่ซับซ้อนและครอบคลุมมากขึ้น โดยถือว่าข้อมูลประจำตัวดิจิทัลเป็นการสะสมข้อมูลผู้ใช้ใน Web3 ต่อไปนี้คือสี่ตัวอย่างที่เกี่ยวข้องโดยเฉพาะ:

• ระบบคำแนะนำ Web3 หวังว่าจะสร้างภาพผู้ใช้ผ่านการสะสมข้อมูลที่เกี่ยวข้องกับ Web3 ของผู้ใช้ จากนั้นจึงดำเนินการแนะนำส่วนบุคคลและการแสดงโฆษณาที่ตรงเป้าหมาย การเล่าเรื่องของภาพผู้ใช้ชุดนี้ได้รับการสืบทอดมาจากตรรกะหลักของผู้ผลิตแพลตฟอร์มในยุคอินเทอร์เน็ตบนมือถือ และได้รับการพิสูจน์แล้วว่าเป็นไปได้ และใน Web3 ไม่เพียงแต่ข้อมูลระบุตัวตนเท่านั้นที่สามารถทำงานร่วมกันในแพลตฟอร์มต่าง ๆ ได้ แต่ผู้ใช้ยังสามารถเป็นเจ้าของและมีสิทธิ์เปิดการแบ่งปันข้อมูลระบุตัวตนของตนเองได้ ระบบภาพประจำตัวผู้ใช้ที่สร้างขึ้นในลักษณะนี้อาจเป็นมิตรกับผู้ใช้มากกว่า Web2

• Web3 ทำความรู้จักปฏิสัมพันธ์ทางสังคม โดยหวังว่าจะสร้างชุดของกราฟทางสังคมของผู้ใช้ผ่านการสะสมปฏิสัมพันธ์ทางสังคมของผู้ใช้ใน Web3 ซึ่งสามารถใช้งานได้โดยแอปใหม่ต่างๆ ด้วยวิธีนี้ เมื่อผู้ใช้ใช้แอปพลิเคชันใหม่หรือเข้าสู่เกมใหม่ พวกเขาสามารถค้นหาคนรู้จักและเพื่อนได้อย่างรวดเร็วโดยไม่ต้องเพิ่มพวกเขาอีกครั้งเหมือน Web2

• สำหรับเกม Web3 เราหวังว่าจะสร้างระบบบัญชีเกม (GameID) เพื่ออธิบายความสนใจและความสามารถของผู้ใช้ในเกมผ่านการสะสมข้อมูลของผู้ใช้ในเกม Web3 ตัวอย่างเช่น ผู้ใช้ A อาจมีบันทึกการเข้าร่วมในช่วงแรกๆ ของเกมไพ่ Web3 บางเกม และสามารถบันทึกสิ่งเหล่านี้ใน GameID ได้ ดังนั้นหากเกมไพ่ใหม่ต้องการหาผู้ใช้ก่อนใคร ก็สามารถให้ A เป็นลำดับความสำคัญก่อนใครได้

• การกำกับดูแลการลงคะแนนเสียงของ DAO บางครั้งหวังว่าจะดำเนินการลงคะแนนอย่างยุติธรรมของ "หนึ่งคน หนึ่งคะแนน" แต่จะพิสูจน์ได้อย่างไรว่าคน ๆ หนึ่งลงคะแนนเพียงครั้งเดียว แทนที่จะลงทะเบียนหลายบัญชีเพื่อรูดคะแนน (การโจมตีแบบซีบิล) นั้นเป็นปัญหาที่ยาก ปัญหานี้สามารถแก้ไขได้ผ่านการวิเคราะห์ประวัติที่อยู่ของผู้ใช้หรือการตรวจสอบบุคคลจริง

1.3 การเชื่อมต่อระหว่างสถานการณ์การใช้งานสองประเภท: จากจุดหนึ่งไปยังอีกจุดหนึ่ง และจากจุดหนึ่งไปอีกจุดหนึ่ง

อันที่จริงแล้ว ความสัมพันธ์ระหว่างแอปพลิเคชัน Reputation และ Relationship นั้นไม่ชัดเจนนัก แต่มีความสัมพันธ์แบบเครือข่ายมากกว่า

เพื่อให้แม่นยำยิ่งขึ้น แท็กต่างๆ ที่ชัดเจนและน่าเชื่อถือเปรียบเสมือน "คะแนน" เมื่อเวลาผ่านไป คะแนนเหล่านี้สะสมรอบๆ ตัวตนเดียวกัน และในที่สุดก็สร้าง "ใบหน้า" ที่สมบูรณ์เกี่ยวกับภาพบุคคลของผู้ใช้ เมื่อผู้ใช้หรือเมื่อกลุ่มโครงการต้องการจริงๆ หากต้องการใช้ "ใบหน้า" นี้ จำเป็นต้องมีการประมวลผลเพิ่มเติมเพื่อลดความซับซ้อนให้เป็น "จุด" ไม่กี่จุดที่อธิบายและเข้าใจได้ง่าย

ยกตัวอย่างเรื่องการถือครอง NFT ในช่วงแรก ๆ ผู้ใช้อาจถูกแท็ก (แต้ม) เท่านั้น เช่น ผู้ถือ BAYC และผู้ถือ Azuki แต่นาน ๆ ไป หากเราพบว่าเมื่อใดก็ตามที่มีคนนิยม NFT ปรากฏขึ้น ผู้ใช้รายนี้จะมีส่วนร่วมในการทำธุรกรรม (ใบหน้า) จากนั้นเราจึงสามารถทำการวิเคราะห์แบบอุปนัยและระบุว่าเขาเป็น "ผู้ค้า NFT ยอดนิยม" (จุด)

ข้อมูลข้างต้นเป็นบทสรุปของเรื่องเล่า DID ทั้งหมดที่ระดับสถานการณ์ของแอปพลิเคชัน จะเห็นได้ว่าโดยพื้นฐานแล้วจะครอบคลุมการเล่าเรื่องเกือบทั้งหมดของเลเยอร์แอปพลิเคชัน Web3 ซึ่งเป็นเหตุผลว่าทำไม DID จึงเรียกอีกอย่างว่า "โครงสร้างพื้นฐานข้อมูลประจำตัว" ของแอปพลิเคชัน Web3

2. แบบฟอร์มข้อมูลดั้งเดิมและข้อมูลประจำตัว: คุณลักษณะที่ประกอบเป็น DID มาจากไหน

ผู้อ่านอาจรู้สึกว่าในเรื่องเล่าข้างต้นของสถานการณ์การใช้งานต่างๆ นั้น แท้จริงแล้วตัวตนดิจิทัลแต่ละอันอ้างอิงถึงสิ่งต่างๆ ที่แตกต่างกัน แต่สามารถเรียกว่า "DID" ได้ทั้งหมด ที่นี่มีสองประเด็นสำคัญ:

• "ข้อมูลประจำตัวที่กระจายอำนาจ" นี้ประกอบด้วยป้ายกำกับ/แอตทริบิวต์/ข้อมูลรับรองเฉพาะใดบ้าง ตัวอย่างเช่น สิ่งที่ต้องการเชื่อมต่อคือการถือครอง NFT ของผู้ใช้ บันทึกการโต้ตอบบนเครือข่าย หรือความสัมพันธ์ทางสังคมของผู้ใช้ หรือข้อมูลประจำตัวของผู้ใช้นอกเครือข่าย

• "เอกลักษณ์ที่กระจายอำนาจ" นี้ ตัวระบุใด (ตัวระบุ, ID) ที่รวมอยู่บน หรืออินเทอร์เฟซหลักสำหรับการโต้ตอบภายนอกคืออะไร ตัวอย่างเช่น เราใช้ NFT, ที่อยู่ หรือชื่อโดเมนเพื่อแสดงข้อมูลประจำตัวหรือไม่ เราจะใช้ข้อมูลประจำตัวเพื่อโต้ตอบกับฝั่งแอปพลิเคชันได้อย่างไร

หลังจากชี้แจงสองประเด็นนี้แล้ว คุณจะเห็นโครงการที่หลากหลายและซับซ้อนใน DID อย่างชัดเจนที่ชั้นข้อมูลประจำตัว

ลองพิจารณาคำถามแรกว่าแอตทริบิวต์ที่ประกอบเป็น DID มาจากไหนกันแน่

2.1 ข้อมูลประจำตัว: เหตุใดจึงมีความสำคัญสำหรับข้อมูลประจำตัวแบบกระจายศูนย์

ลองดูตัวอย่างต่อไปนี้ก่อน: คุณพบคนใหม่ และเขาพูดว่า “ฉันชื่อจางซาน เกิดในปี 1990 จบการศึกษาระดับปริญญาตรีจากมหาวิทยาลัยปักกิ่ง และฉันรู้จักพ่อของคุณเป็นอย่างดี” เขาต้องการบางอย่างจากคุณ แต่ด้วยเหตุผลบางอย่าง คุณมีความไม่ไว้วางใจอย่างมากต่อการแนะนำตัวเองของเขา แล้วเขาจะพิสูจน์ความจริงที่เขาพูดให้คุณเห็นได้อย่างไร?

หากต้องการพิสูจน์ชื่อและอายุก็สามารถแสดงบัตรประจำตัวประชาชนและยังสามารถไปสถานีตำรวจพร้อมกับคุณเพื่อพิสูจน์ว่าบัตรประจำตัวประชาชนเป็นของตนเองหากต้องการพิสูจน์การศึกษาก็สามารถแสดงได้ บัตรประจำตัวประชาชน ใบรับรองการสำเร็จการศึกษา หรือใบรับรองที่ Xuexin.com ส่งถึงคุณ หากเขาต้องการพิสูจน์ว่าเขารู้จักพ่อของคุณเป็นอย่างดี เขาสามารถติดต่อพ่อของคุณเพื่ออธิบายให้คุณฟังได้ ในทางกลับกัน หากเขาถามคุณและต้องการพิสูจน์ตัวตนของเขา แต่เขาไม่ได้ให้หลักฐานเฉพาะที่กล่าวถึงข้างต้นเมื่อคุณขอให้เขาทำเช่นนั้น คุณก็มีเหตุผลเพียงพอที่จะสงสัยในความถูกต้องของข้อความของเขา

ดังนั้น เราจะเห็นว่าตัวตนนั้นประกอบด้วยคุณลักษณะหลายอย่าง เช่น ชื่อ ปีเกิด การศึกษา วงสังคม และคุณลักษณะอื่นๆ ที่เกี่ยวข้องกับคำกล่าวของจางซานที่มีต่อตัวเขาในตอนนี้ อย่างไรก็ตาม หากไม่มีข้อมูลประจำตัวที่สอดคล้องกัน แอตทริบิวต์เหล่านี้ก็จะไม่น่าเชื่อถือ และสถานการณ์แอปพลิเคชันส่วนใหญ่จะไม่ใช้ข้อมูลประจำตัวดิจิทัลโดยไม่มีความน่าเชื่อถือ เนื่องจากใน Web3 แหล่งที่มาของแอตทริบิวต์ของข้อมูลประจำตัวมีความหลากหลายมากขึ้น และผู้ใช้ที่มีศักยภาพก็กว้างขึ้น จึงเป็นเรื่องยากที่จะหาผู้ค้ำประกันทั่วไปจากส่วนกลาง ดังนั้นการตรวจสอบข้อมูลประจำตัวสำหรับแต่ละแอตทริบิวต์จึงมีความโดดเด่นมากขึ้น

2.2 การจำแนกประเภทของแหล่งข้อมูลดั้งเดิมของ Voucher

ดังนั้น เมื่อเราศึกษาองค์ประกอบเฉพาะของ DID เราจะมุ่งเน้นไปที่ข้อมูลรับรองเฉพาะ

ข้อมูลบนเครือข่ายของผู้ใช้เป็นแหล่งข้อมูลประจำตัวที่เป็นธรรมชาติและใช้งานง่ายที่สุด เนื่องจากลักษณะที่บล็อกเชนพื้นฐานไม่สามารถแก้ไขได้ แม้แต่ความไว้วางใจประเภทนี้ก็สามารถขึ้นอยู่กับห่วงโซ่สาธารณะที่สำคัญเท่านั้น โดยไม่จำเป็นต้องมีผู้ออกใบรับรองเฉพาะ ตัวอย่างเช่น เพื่อพิสูจน์ว่าที่อยู่กระเป๋าเงิน A ได้โอนเงินไปยังที่อยู่กระเป๋าเงิน B จริง ๆ คุณจะต้องตรวจสอบข้อมูลที่สอดคล้องกันในห่วงโซ่ ความน่าเชื่อถือประเภทนี้หากไม่มีผู้ออกใบรับรองนั้นไม่มีอยู่ในแหล่งข้อมูลใบรับรองอื่น ๆ และยังเป็นหนึ่งในเสน่ห์หลักของบล็อกเชนอีกด้วย มีผลิตภัณฑ์เครื่องมือ Web3 ค่อนข้างน้อยที่ทำการวิเคราะห์ข้อมูลแบบบูรณาการบนห่วงโซ่

อย่างไรก็ตาม ในโลกของ Web3 ปัจจุบัน ข้อมูลบนเครือข่ายส่วนใหญ่ประกอบด้วยการถ่ายโอน การโต้ตอบกับ DeFi และธุรกรรม/การถือครอง NFT และข้อมูลระบุตัวตนที่สามารถนำมาได้นั้นมีจำกัด อย่างไรก็ตาม ในโลกแห่งความเป็นจริง ข้อกำหนดเบื้องต้นสำหรับเราในการเชื่อถือใบรับรองในหลายกรณีคือการเชื่อถือผู้ออกใบรับรอง แต่การสร้างความสัมพันธ์ที่น่าเชื่อถือนี้อยู่ใน Web2 หรือในโลกแห่งความเป็นจริง ในหลายกรณี เป็นเรื่องยากสำหรับเราที่จะรวมกระบวนการตรวจสอบทั้งหมดไว้ในห่วงโซ่ เช่น ใบขับขี่ แม้ว่าจะเป็นข้อมูลดิจิทัล แต่การทดสอบก็ยังคงเกิดขึ้นในโลกแห่งความเป็นจริง

ปัจจุบัน มีสามรูปแบบหลักในการสร้าง Web2 และข้อมูลในโลกแห่งความเป็นจริงและความสัมพันธ์ที่ไว้วางใจให้เป็นข้อมูลประจำตัวที่น่าเชื่อถือ: SBT, VC และ PoP

2.2.1 โทเค็นผูกวิญญาณ (SBT)

SBT (Soul Bound Token) หรือ Soul Bound Token เป็นแนวคิดใหม่ที่อธิบายไว้ในบทความ "Decentralized Society" ที่เผยแพร่โดย Vitalik และคณะ ในเดือนพฤษภาคม 2565

เนื่องจากปัจจุบัน SBT ยังไม่มีมาตรฐานที่ชัดเจนร่วมกัน อันที่จริง SBT ในปัจจุบันสามารถเข้าใจง่ายๆ ได้ว่าเป็นโทเค็นที่ไม่สามารถถ่ายโอนได้ นั่นคือ "โทเค็นที่ไม่สามารถถ่ายโอนได้" อันที่จริง ข้อมูลรับรองในรูปแบบของโทเค็นดังกล่าวมีอยู่แล้ว เช่น ที่ออกโดย POAP, Project Galaxy

การใช้งาน SBT นั้นง่ายที่สุด และเป็นธรรมชาติที่มีการทำงานร่วมกันและการเปิดกว้างที่ดีมาก และเนื่องจาก SBT เป็นแบบเนทีฟบนเชน จึงสามารถใช้เป็น "ใบรับรองผลลัพธ์" สำหรับวิธีการวิเคราะห์ข้อมูลแบบออนเชน เช่น การให้คะแนนเครดิตแบบออนเชน

ปัญหาหลักของ SBT คือปัญหาเกี่ยวกับความเป็นส่วนตัวของผู้ใช้ที่เกิดจากการเปิดกว้าง ลักษณะสาธารณะของ SBT ช่วยให้ใครก็ตามสามารถเชื่อมโยงและอนุมานเกี่ยวกับบุคคลได้ง่าย และอาจทำให้ความเป็นส่วนตัวเป็นไปไม่ได้และส่งเสริมการเลือกปฏิบัติบางรูปแบบ ตัวอย่างเช่น นายจ้างที่เหยียดผิวอาจเลือกปฏิบัติต่อพนักงานที่มีศักยภาพ เพราะการแอบดูกระเป๋าเงินของผู้สมัครงานเป็นการเปิดเผยเหตุการณ์ Black Lives Matter

ในทางทฤษฎี ด้วยการผสมผสานระหว่างเทคโนโลยี ZK และ SBT ทำให้สามารถรับรู้ถึงการปกป้องความเป็นส่วนตัวของผู้ใช้ได้ แต่สิ่งนี้ไม่เพียงเกี่ยวข้องกับปัญหาบางประการในการใช้งานด้านเทคนิคเฉพาะเท่านั้น แต่ยังอาจส่งผลต่อความเปิดกว้างและการทำงานร่วมกันของ SBT

2.2.2 ใบรับรองที่ตรวจสอบได้ (VC)

ข้อมูลประจำตัวที่ตรวจสอบได้ การแปลตามตัวอักษร "ใบรับรองที่ตรวจสอบได้"

บางคนเริ่มคิดถึงการกระจายอำนาจในโลกดิจิตอล VC ยังเป็นส่วนหนึ่งของแนวคิดและระบบมาตรฐานที่เสนอโดย W3C

ให้เราเข้าใจ VC โดยสัญชาตญาณผ่านตัวอย่างการรับรองใบขับขี่สากลต่อไปนี้:

• หาก Hans ชาวเยอรมันได้รับใบอนุญาตขับขี่ เขาสามารถยื่นคำร้องต่อรัฐบาลเยอรมนีเพื่อออกและลงนามใน VC ด้วยตัวระบุแบบกระจายศูนย์ (DID) VC นี้มีอยู่ในรูปของเอกสารดิจิทัล ซึ่งเป็นใบรับรองสำหรับ Hans ในการรับใบขับขี่ และ Hans เป็นผู้เก็บรักษาเอง

• ถ้า Hans ไปออสเตรเลียและเริ่มทัวร์ขับรถด้วยตนเอง เมื่อเขาจำเป็นต้องแสดงใบขับขี่ เขาสามารถแสดงให้รัฐบาลออสเตรเลียเห็น VC ที่เขาได้รับจากทางการเยอรมัน เจ้าหน้าที่ออสเตรเลียเห็นเอกสารดิจิทัลนี้ซึ่งลงนามโดย ID ของทางการเยอรมัน และข้างต้น หลังจากทราบข้อมูลแล้ว ถือได้ว่า Hans มีความสามารถในการขับขี่

แม้ว่าพูดอย่างเคร่งครัด การเขียนเฉพาะของ VC มีชุดมาตรฐานที่กำหนดโดย W3C และตัวระบุแบบกระจายอำนาจในนั้นยังเป็น DID ในระบบ W3C แต่จากมุมมองของ Web3 มีความเป็นไปได้เชิงตรรกะที่จะแทนที่ตัวระบุแบบกระจายอำนาจนี้ด้วยที่อยู่กระเป๋าเงินในความหมายกว้าง ๆ รูปต่อไปนี้แสดงความสัมพันธ์ระหว่างผู้ใช้ ผู้ออก VC และผู้ตรวจสอบ VC :

จะเห็นได้ว่าเมื่อเปรียบเทียบกับ SBT แล้ว ข้อได้เปรียบหลักของ VC อยู่ที่การปกป้องความเป็นส่วนตัวของผู้ใช้ และผู้ใช้สามารถเลือกที่จะเปิดเผยข้อมูลของตนเองได้อย่างเป็นธรรมชาติ ยิ่งไปกว่านั้น การนำไปปฏิบัตินั้นไม่เกี่ยวข้องกับเทคโนโลยีบล็อกเชนเลย นั่นคือมันยังเข้ากันได้ดีกับ Web2

ปัญหาหลักของ VC คือแม้ว่าจะมีชุดมาตรฐานที่ได้รับการยอมรับค่อนข้างมาก แต่ชุดมาตรฐานนี้ต้องการการสนับสนุนของ DID (ดูรายละเอียดด้านล่าง) และความก้าวหน้าของ DID นั้นค่อนข้างช้า หากฝ่ายโครงการหรือชุมชน Web3 ต้องการกำหนดชุดมาตรฐานกระบวนการปฏิบัติการของ VC วิธีส่งเสริมมาตรฐานนี้ก็จะเป็นจุดที่ยากเช่นกัน

2.2.3 การพิสูจน์บุคลิกภาพ (PoP)

การพิสูจน์ความเป็นบุคคล สิ่งสำคัญที่ต้องทำคือการพิสูจน์เอกลักษณ์ของตัวตนดิจิทัลโดยการผูกข้อมูลของบุคคลจริงภายใต้ห่วงโซ่ Proof of Humanity, BrightID และ IDNA เป็นตัวแทนโครงการในหมู่พวกเขา

การรับรู้ที่เฉพาะเจาะจงส่วนใหญ่ผ่านสองเทคโนโลยีของ KYC และการจดจำใบหน้าผ่านวิดีโอ KYC เป็นวิธีการยืนยันตัวตนแบบคลาสสิกที่เป็นที่นิยมในการแลกเปลี่ยน ผ่าน KYC ข้อมูลระบุตัวตนดิจิทัลจะผูกมัดกับข้อมูลนิติบุคคลของคุณ (ชื่อ สัญชาติ ฯลฯ) ภายใต้เชน การจดจำใบหน้า เช่น BrightID จะใช้ข้อมูลใบหน้าของคุณเป็นหลัก ฐานข้อมูลเพื่อให้แน่ใจว่าบุคคลสามารถลงทะเบียนหนึ่งรหัสในระบบรหัสโครงการ

จะเห็นได้ว่าสถานการณ์แอปพลิเคชันที่ตรงที่สุดของการตรวจสอบความถูกต้องของ PoP คือการโจมตีแบบต่อต้านซีบิล นอกจากนี้ ภายใต้เบื้องหลังที่ทุกประเทศกำลังพิจารณากฎระเบียบเกี่ยวกับสกุลเงินดิจิทัล KYC อาจกลายเป็นเงื่อนไขที่จำเป็นสำหรับการจัดตั้ง "ข้อมูลประจำตัวทางกฎหมาย"

2.3 รายการที่เกี่ยวข้องของบัตรกำนัล

จะเห็นได้ว่าแม้ว่าองค์ประกอบเฉพาะของข้อมูลประจำตัวดิจิทัลแบบกระจายศูนย์อาจมีความซับซ้อนมาก แต่ในการวิเคราะห์ขั้นสุดท้าย จะประกอบด้วยข้อมูลรับรองสี่ประเภทต่อไปนี้เป็นหลัก: ข้อมูลดั้งเดิมในห่วงโซ่ SBT, VC และ PoP

พูดตามตรง SBT ก็เป็นส่วนหนึ่งของข้อมูลดั้งเดิมบนห่วงโซ่เช่นกัน แต่ SBT จะต้องได้รับการประมวลผลใหม่ในทางใดทางหนึ่ง และความเชื่อถืออาจขึ้นอยู่กับผู้ออก ในขณะที่ความเชื่อถือในข้อมูลดั้งเดิมบนห่วงโซ่จะต้องขึ้นอยู่กับพื้นฐานเท่านั้น ความไว้วางใจในห่วงโซ่สาธารณะ

โครงการ Web3 ประเภทใดที่เกี่ยวข้องกับข้อมูลประจำตัว

ในกรณีส่วนใหญ่ กฎการรับรองความถูกต้องของใบรับรองจำนวนมากมีความสามารถในการทำงานร่วมกันสูง เช่น การตรวจสอบว่าผู้ใช้ทำธุรกรรมในห่วงโซ่สำเร็จหรือไม่ ตรวจสอบว่าผู้ใช้ช่วยส่งต่อ Twitter ของฝ่ายโครงการหรือไม่ หรือการตรวจสอบว่าบุคคลจริงที่อยู่เบื้องหลังผู้ใช้คือ ความพยายามครั้งแรกในการรับข้อมูลประจำตัว ในบริบทนี้ ผู้ออกใบรับรองเองไม่จำเป็นต้องสร้างชุดเครื่องมือสำหรับการออกใบรับรอง

ดังนั้น ประเภทโครงการจำนวนมากในส่วนนี้จึงเป็นเครื่องมือ/แพลตฟอร์มสำหรับการออกใบรับรอง ยกตัวอย่าง Project Galaxy ฝ่ายโครงการสามารถเผยแพร่งานบน Project Galaxy และผู้ใช้สามารถรับข้อมูลประจำตัวที่ออกโดยฝ่ายโครงการหลังจากเสร็จสิ้นงานบนแพลตฟอร์มและทำการตรวจสอบสิทธิ์

อย่างไรก็ตาม ในบางสถานการณ์ที่ซับซ้อน ผู้ออกใบรับรองหวังว่าจะออกแบบกฎของตนเองเพื่อรับรองความถูกต้องของผู้ใช้ โดยเฉพาะอย่างยิ่งในสถานการณ์ที่ซับซ้อนซึ่งการประเมินขึ้นอยู่กับระดับที่กำหนด ใบรับรองพิสูจน์บุคลิกภาพที่กล่าวถึงก่อนหน้านี้ยังสามารถจัดประเภทเป็นโครงการออกใบรับรอง

ตัวอย่างอื่นๆ ได้แก่:

• Rabbithole เป็นตัวแทนของโครงการ "ใบรับรองการเรียนรู้" ให้การรับรองชื่อ Web3 ต่างๆ (เช่น NFT Creator, Explorer เป็นต้น) ซึ่งกำหนดให้ผู้ใช้ทำงานที่ซับซ้อนมากขึ้น ในระดับหนึ่ง ตรรกะและเครือข่ายออนไลน์ ใบรับรอง การจบหลักสูตรมีความคล้ายคลึงกันมาก และ Rabbithole ยังสามารถกล่าวได้ว่าเป็นต้นแบบของ "การศึกษาออนไลน์ Web3"

• ARCx หวังที่จะวัดมูลค่าความน่าเชื่อถือของที่อยู่แบบเครือข่ายโดยพิจารณาจากคะแนนเครดิตของผู้ถือ DeFi Passport แต่ละราย คะแนนเครดิตจะถูกกำหนดโดยการวิเคราะห์กิจกรรมในอดีตของที่อยู่ Ethereum ของผู้ถือ และช่วงของคะแนนถูกกำหนดจาก 0 ถึง 999 คะแนน คะแนนเครดิตกำหนดอัตราการจดจำนองที่โปรโตคอลกำหนดให้กับผู้ใช้ สำหรับที่อยู่ที่มีคะแนนเครดิตสูง DeFi Passport สามารถให้หลักประกันเงินกู้ที่แข่งขันได้

• FirstBatch หวังที่จะใช้ AI เพื่อสร้างแท็กความสนใจของผู้ใช้บนเครือข่ายโดยการอ่านข้อมูลการให้สิทธิ์ผู้ใช้บนโซเชียลมีเดียของ Web2 และใช้เทคโนโลยี ZK เพื่อการปกป้องความเป็นส่วนตัว

3. Identity Layer: การเชื่อมต่อของสถานการณ์แอปพลิเคชันและข้อมูลประจำตัว แบบฟอร์ม DID เฉพาะ

เราได้กล่าวถึงสถานการณ์การใช้งานเฉพาะของ DID และยังได้กล่าวถึงองค์ประกอบเฉพาะของข้อมูลประจำตัวของ DID สิ่งที่เชื่อมโยงกรณีการใช้งานและข้อมูลรับรองคือสิ่งที่โครงการเลเยอร์ข้อมูลประจำตัวทำ ตัวอย่างเช่น ชื่อโดเมน กระเป๋าเงิน กราฟสังคม การวิเคราะห์การเชื่อมโยงที่อยู่...

จะแยกแยะได้อย่างไรว่าโครงการกำลังทำการรวมข้อมูลประจำตัวหรือไม่ ในที่นี้ ผู้เขียนขอเสนอวิธีการตัดสิน: หากโปรเจ็กต์ (หรือโมดูลโปรเจ็กต์) ทำบางสิ่งที่ไม่ใช้ DID ในสถานการณ์ที่มุ่งเน้นผู้ใช้เฉพาะ หรือสร้างข้อมูลประจำตัวใหม่สำหรับผู้ใช้ สิ่งสำคัญที่ต้องทำคือ "การผูกมัด" ต่างๆ หากเป็น คงที่” และ “เชื่อมต่อ” จากนั้นมีความเป็นไปได้สูงที่จะเป็นรายการของเลเยอร์การรวมข้อมูลประจำตัว

แต่วิธีการรวมข้อมูลประจำตัวของ Web3 โครงการประเภทต่างๆ ให้เส้นทางและวิธีคิดที่แตกต่างกัน สามารถแบ่งออกเป็นสองประเภทอย่างคร่าว ๆ ได้แก่ การประมวลผลและการรวมข้อมูลดิบและข้อมูลรับรองต่าง ๆ บนห่วงโซ่ และเครื่องมือการจัดการข้อมูลประจำตัวที่เน้นผู้ใช้เป็นหลักและช่วยให้ผู้ใช้บรรลุอำนาจอธิปไตยของข้อมูล

3.1 โปรโตคอลการรวมข้อมูล

ข้อมูลของผู้ใช้ในเชนมักจะกระจัดกระจายอยู่ในเชนสาธารณะหลายอันและสัญญาอัจฉริยะหลายโปรเจกต์ ดังนั้นจึงจำเป็นต้องประมวลผลและรวมเข้าด้วยกันเพื่อสร้างข้อมูลประจำตัว หลายโครงการกำลังทำโปรโตคอลการรวบรวมข้อมูลดังกล่าว

ข้อตกลงเหล่านี้มักไม่มีผลิตภัณฑ์ที่มุ่งเน้นไปที่ผู้ใช้โดยตรง ข้อตกลงเหล่านี้มุ่งเน้นไปที่ฝ่ายโครงการและข้อตกลงอื่น ๆ เป็นหลัก และสามารถร่วมมือกันในการรวบรวมข้อมูล ตัวอย่างมีดังนี้:

• Cyberconnect หวังที่จะสร้างกราฟโซเชียลบนเครือข่าย โดยรวบรวมข้อมูลความสัมพันธ์ทางสังคมของผู้ใช้

• เครือข่าย KNN3 หวังที่จะสร้างกราฟความสัมพันธ์ทางสังคมของผู้ใช้ในหลายเครือข่ายผ่านการรวมการวิเคราะห์ความสัมพันธ์ของรอยเท้า, Cyberconnect และกราฟทางสังคมอื่น ๆ

• RSS3 หวังว่าจะเป็นการรวมเนื้อหาและข้อมูลทางสังคมบนเครือข่าย และอาจพัฒนาไปในทิศทางของระบบกระจายและแนะนำข้อมูล Web3

โครงการเครื่องมือการจัดการข้อมูลประจำตัวประเภทต่อไปนี้ล้วนหวังที่จะให้ผู้ใช้มีความสามารถในการจัดการข้อมูลประจำตัว ซึ่งเป็นเครื่องมือโดยตรงสำหรับผู้ใช้ในการบรรลุอำนาจอธิปไตยของข้อมูล

3.2 เครื่องมือจัดการข้อมูลประจำตัว - กระเป๋าเงิน

กระเป๋าเงินนั้นมุ่งเน้นที่ผู้ใช้โดยตรงและปัจจุบันได้รับการยอมรับว่าเป็น "ทางเข้า Web3" แม้ว่าจะไม่สามารถกล่าวได้ว่าเป็นสถานการณ์ของแอปพลิเคชัน DID แต่เป็นช่องทางธรรมชาติที่เชื่อมต่อสถานการณ์ของแอปพลิเคชันและข้อมูลรับรองผู้ใช้

"กระเป๋าเงิน DID" ในอุดมคติอาจมีลักษณะดังนี้ ประการแรก สามารถรวมที่อยู่ของเชนสาธารณะหลักทั้งหมด และรวมข้อมูลแยกส่วนของผู้ใช้บนเชนต่างๆ ในขณะที่มีลายเซ็นพื้นฐาน การถ่ายโอน และธุรกรรมอื่นๆ ประการที่สอง สามารถแสดงรายการต่างๆ ข้อมูลรับรอง SBT/VC/PoP ที่เป็นของผู้ใช้ เมื่อโต้ตอบกับโครงการแอปพลิเคชัน ผู้ใช้สามารถอนุญาตอิสระว่าจะเปิดเผยข้อมูลใดกับโครงการ ซึ่งจะช่วยให้ผู้ใช้ตระหนักถึงอำนาจอธิปไตยของข้อมูล กระเป๋าเงินจำนวนมากจะกล่าวถึงเรื่องราวของ DID เช่น Unipass, ABT Wallet, Selfkey เป็นต้น

อย่างไรก็ตาม กระเป๋าเงินกระแสหลักเช่น Metamask ไม่มีฟังก์ชันเหล่านี้ เหตุผลที่สำคัญคือโดยพื้นฐานแล้วมันเป็นกระเป๋าเงิน EOA และกระเป๋าเงินเหล่านี้โดยพื้นฐานแล้วรองรับเฉพาะการดำเนินการดั้งเดิมที่สุดของที่อยู่บนห่วงโซ่ - การสืบค้นและการโอน กระเป๋าเงินสัญญาอัจฉริยะคาดว่าจะขยายฟังก์ชั่นกระเป๋าเงินได้มากขึ้น มีความท้าทายมากมายในการใช้เทคโนโลยีที่เกี่ยวข้องกับกระเป๋าเงิน DID แต่ก็คุ้มค่ากับการรอคอยเช่นกัน

3.3 เครื่องมือจัดการข้อมูลประจำตัว - ชื่อโดเมน

แม้ว่าเราแต่ละคนจะมีหมายเลขประจำตัวที่ไม่ซ้ำกัน แต่ในชีวิตประจำวัน เรามักจะใช้ "ชื่อ" เป็นตัวระบุตัวตนของบุคคล (แม้ว่าอาจมีชื่อซ้ำกัน) เนื่องจากสะดวกกว่าสำหรับการสื่อสารในชีวิตประจำวัน

โลกของ Web3 ก็ประสบปัญหานี้เช่นกัน แม้ว่าการโต้ตอบในปัจจุบันของผู้คนจะอิงตามที่อยู่กระเป๋าเงินเป็นหลัก แต่ก็ไม่มีใครเต็มใจที่จะจำสตริงยาวๆ นั้น หากตัวตนดิจิทัลของ Web3 ต้องการ "ชื่อ" ดังนั้นสิ่งที่โครงการชื่อโดเมนทำคือกลายเป็น "ชื่อ" นี้

ENS เป็นโครงการที่เป็นที่รู้จักมากที่สุดในชื่อโดเมน โดยได้รับการสนับสนุนอย่างเป็นทางการจาก Ethereum Foundation และให้บริการจดทะเบียนชื่อโดเมนด้วย .eth ต่อท้าย ปัจจุบันมีการลงทะเบียนเกือบ 1.8 ล้านครั้ง เป็นที่น่าสังเกตว่า SpruceID ทำงานร่วมกับ ENS เพื่อโปรโมต EIP-4361: Sign In With Ethereum หากดำเนินการตามข้อเสนอได้สำเร็จ จะแทนที่ Connect Wallet ทำให้ชื่อโดเมนกลายเป็นทางเข้าของ Web3 เหนือที่อยู่กระเป๋าเงิน นอกจากนี้ ENS ยังหวังที่จะบรรลุวิสัยทัศน์ของ "ชื่อ Web3" ผ่านการรวมชุดข้อมูลประจำตัวในชื่อโดเมน

อีกโครงการชื่อโดเมนที่ควรค่าแก่การให้ความสนใจคือ Space ID ซึ่งได้รับการสนับสนุนอย่างเป็นทางการจาก Binance และให้บริการจดทะเบียนชื่อโดเมนด้วย .bnb ต่อท้าย Space ID ยังหวังที่จะระบุชื่อโดเมน .bnb และที่อยู่หลายแห่งของผู้ใช้ในเครือข่ายต่างๆ รวมถึงบัญชี Twitter ของผู้ใช้และบัญชี Web2 อื่นๆ เพื่อให้กลายเป็นชื่อสากลในฟิลด์ Web3 เมื่อเทียบกับ ENS ความเร็วในการทำซ้ำของผลิตภัณฑ์และความเร็วในการลงจอดของ Space ID จะเร็วกว่า

นอกจาก ENS และ Space ID แล้ว .bit และ Unstoppable Domain ยังเพิ่งเสร็จสิ้นการจัดหาเงินทุนจำนวนมากอีกด้วย เรื่องเล่าที่พวกเขาเล่าเกี่ยวกับ DID นั้นเหมือนกันทุกประการ

เป็นที่น่าสังเกตว่าแม้ว่าทั้งชื่อโดเมนและกระเป๋าเงินสามารถใช้เป็นเครื่องมือในการจัดการข้อมูลประจำตัวได้ แต่บทบาทของพวกเขานั้นแตกต่างกันมาก พวกเขาไม่ขัดแย้งกันในทางทฤษฎี แต่สามารถทำงานร่วมกันอย่างใกล้ชิด: กระเป๋าเงินสามารถใช้ชื่อโดเมนแทนชื่อบัญชีกระเป๋าเงิน และใช้เป็น "ชื่อ" เมื่อโต้ตอบกับแอปพลิเคชัน ชื่อโดเมนยังสามารถรวมหลายๆ ที่อยู่ในเครือหรือแม้แต่บัญชีกระเป๋าเงินหลายบัญชี

3.4 เครื่องมือจัดการข้อมูลประจำตัวอื่น ๆ - ใช้ Next.ID เป็นตัวอย่าง

นอกจากนี้ยังมีผลิตภัณฑ์การจัดการเอกลักษณ์บางอย่าง ความเข้าใจเฉพาะของการใช้งานการจัดการข้อมูลประจำตัวนั้นแตกต่างจากโครงการก่อนหน้านี้ แต่แกนหลักของงานคือการเชื่อมต่อและการรวมตัวที่หลากหลาย และไม่ได้จำกัดเฉพาะสาขาเฉพาะ ฉันหวังว่าจะสร้างเครือข่าย รวมเอกลักษณ์กว้าง ยกตัวอย่าง Next.ID ซึ่งเป็นผลิตภัณฑ์การจัดการข้อมูลประจำตัวใหม่ที่ผลิตโดย Mask Network

Next.ID เป็นผลิตภัณฑ์ที่มุ่งเน้นผู้ใช้ ในเวอร์ชัน V1 ผู้ใช้สามารถใช้ Mask Network เพื่อรับรู้การเชื่อมต่อและการรวมบัญชีแพลตฟอร์ม Web2 และที่อยู่กระเป๋าเงินห่วงโซ่สาธารณะของ Web3 และสามารถจัดการข้อมูลประจำตัวที่ใช้งานอยู่ เมื่อเปรียบเทียบกับชื่อโดเมนและ DID แล้ว Next.ID ก็อยู่ในการรวมด้วยเช่นกัน ของข้อมูลประจำตัวดิจิทัลที่รวมเป็นหนึ่ง ไม่มีการเน้นย้ำถึงตัวระบุที่ชัดเจน แต่หวังว่าหลังจากการรวมข้อมูลประจำตัวแล้ว ข้อมูลดังกล่าวจะถูกสร้างเป็นโครงสร้างพื้นฐานสำหรับการโทรผ่านแอป หาก Next.ID เริ่มโปรโมตชื่อโดเมนของตนเอง หรือโปรโมตตัวระบุ เช่น ชื่อผู้ใช้บัญชี Mask สิ่งที่ทำจะมีความซ้ำซ้อนในระดับหนึ่งกับโครงการชื่อโดเมน เช่น Space ID และ ENS

แต่นอกเหนือจากการรวมตัวในฝั่งผู้ใช้แล้ว นักพัฒนาสามารถใช้ระบบ Avatar ของ Next.ID เพื่อตระหนักถึงการทำงานร่วมกันระหว่างการดำเนินการเฉพาะของบัญชีผู้ใช้ในผลิตภัณฑ์ของตนกับ Next.ID ดังที่แสดงในรูปด้านล่าง ซึ่งทำได้หลายอย่าง ในระดับหนึ่ง สิ่งที่โปรโตคอลการรวมข้อมูลประจำตัวต้องการทำ คุณยังสามารถเลือกที่จะร่วมมือกับโปรโตคอลเหล่านี้และรวมเข้าด้วยกันอีกครั้ง

ที่มา: เอกสารอย่างเป็นทางการของ Next.ID

3.5 เครื่องมือจัดการเอกลักษณ์ฉากท้องถิ่น

3.5.1 GameID

นอกเหนือจากโครงการเครื่องมือการจัดการข้อมูลประจำตัวบางโครงการที่หวังว่าจะรวมข้อมูลผู้ใช้ทั่วทั้งเครือข่ายแล้ว ยังมีบางโครงการที่สร้างเครื่องมือการจัดการข้อมูลประจำตัวตามสถานการณ์ในพื้นที่

ตัวอย่างที่เข้าใจง่ายคือ GameID ที่รวบรวมข้อมูลผู้ใช้เกี่ยวกับเกมต่างๆ ในเครือ เช่น Loots ซึ่งได้รับความนิยมเมื่อปีที่แล้ว

ID ใน GameID อ้างอิงถึงระบบบัญชีที่สื่อสารภายในระบบนิเวศมากกว่า คล้ายกับบัญชี Shanda และบัญชี QQ ใน Web2 พวกเขาต้องการอธิบายลักษณะของผู้ใช้ภายในระบบนิเวศเท่านั้นไม่ใช่ผู้ใช้ที่เป็นตัวแทน ของข้อมูลประจำตัวดิจิทัลทั่วทั้งเครือข่าย

ดังนั้น แทนที่จะบอกว่าเป็น DID จะเป็นการดีกว่าหากจะบอกว่าเป็นเศษชิ้นส่วนของจิ๊กซอว์ของ DID ของผู้ใช้

ตัวอย่างเช่น Zhang San จดทะเบียนชื่อโดเมน zhangsan.eth รหัส "Shanda" ของเขาคือ 123456 ซึ่งมีใบรับรอง 5 ใบจากโครงการเกม "Shanda Series" ที่แตกต่างกัน ID "Tencent" ของเขาคือ 567890 ซึ่งมีใบรับรอง 9 ใบจาก " "Tencent ใบรับรองโครงการเกมซีรีส์ ดังนั้น แม้ว่า "Shanda" และ "Tencent" อาจมีเครื่องมือจัดการข้อมูลประจำตัวเฉพาะเพื่อช่วยผู้ใช้จัดการบัญชีแพลตฟอร์มที่เกี่ยวข้อง แต่เครื่องมือทั้งหมดสามารถรวมเข้าด้วยกันโดย "ชื่อ Web3" ของ zhangsan.eth และกลายเป็นส่วนหนึ่งของข้อมูลประจำตัว zhangsan.eth . ป้ายกำกับ.

3.5.2 DIDs

หลังจากการวิจัยและการอภิปรายเป็นเวลาหลายปี ในที่สุด W3C ก็เปิดตัวมาตรฐานที่เป็นทางการ v1.0 สำหรับตัวระบุแบบกระจายอำนาจ (DIDs, ตัวระบุแบบกระจายอำนาจ) ในเดือนกรกฎาคม 2022 เนื่องจากคำจำกัดความเริ่มต้นของ "DID" จึงจำเป็นต้องชี้แจงความสัมพันธ์ระหว่าง DID ของ W3C และระบบ Web3 DID ปัจจุบันด้วย

ในสถาปัตยกรรมตัวระบุแบบกระจายอำนาจมาตรฐาน W3C ผู้ใช้จะควบคุมตัวระบุและเอกสารที่เกี่ยวข้องได้โดยตรง APP สามารถอ่านเอกสารที่เชื่อมโยงกับ DID โดยได้รับอนุญาตจากผู้ใช้เพื่อทำธุรกิจ เอกสารประกอบด้วยข้อมูลดิจิทัลที่เกี่ยวข้องกับตัวตน เช่น ลายเซ็น ข้อมูลที่เข้ารหัส และอื่นๆ ผู้ใช้พิสูจน์ความเป็นเจ้าของ DID ผ่านลายเซ็นเข้ารหัส ข้อมูลผู้ใช้ถูกจัดเก็บไว้ในฐานข้อมูลที่เชื่อถือได้ (เช่น บล็อกเชน) และข้อมูลระบุตัวตนไม่ได้ขึ้นอยู่กับแอป

DID มีสามองค์ประกอบดังแสดงในรูปด้านล่าง DID scheme คล้ายกับ http, ipfs และการประกาศเมธอดอื่นๆ วิธี DID คือตัวระบุสำหรับเมธอดเฉพาะ แต่ละโปรเจ็กต์ที่ต้องการสร้างระบบระบุตัวตน DID สามารถสมัครได้ ตัวอย่างเช่น Tencent สามารถใช้ตัวระบุ tencentqq สำหรับ QQ ตัวระบุเฉพาะวิธี DID เป็นรหัสเฉพาะและการใช้งานจะขึ้นอยู่กับคำจำกัดความของกลุ่มโครงการเฉพาะ ตัวอย่างเช่น Tencent สามารถใช้ did:tencentqq:123456789 QQ เลขที่ 123456789.

ขั้นตอนการดำเนินงานโดยละเอียดและรายละเอียดทางเทคนิคของ DID นั้นค่อนข้างซับซ้อน ดังนั้นฉันจะไม่แนะนำโดยละเอียดที่นี่

DID แข่งขันกับชื่อโดเมน Web3 ในระดับหนึ่ง นี่คือการเปรียบเทียบความแตกต่างหลักระหว่าง DID และชื่อโดเมน:

• ในแง่ของความสามารถในการอ่าน DID ขาดความสามารถในการอ่านระดับผู้ใช้เมื่อเทียบกับชื่อโดเมน แต่เนื่องจากการมีอยู่ของวิธี DID จึงสามารถมีความหมายพิเศษอีกชั้นหนึ่งและมีความยืดหยุ่นที่ดีกว่า

• ในแง่ของศักยภาพของการรวมข้อมูล DID ร่วมกับวิธีการตรวจสอบเช่น VC สามารถรวมข้อมูลนอกเครือข่ายได้มากขึ้นในทางทฤษฎี โดยเฉพาะใบรับรองดิจิทัลที่จัดทำโดยองค์กรที่มีอำนาจ ในปัจจุบัน การรวมข้อมูลของโครงการชื่อโดเมนยังคงอิงตาม อิงตามข้อมูลของเชน ถ้าคุณต้องการการรวมข้อมูลนอกเชนที่ดีขึ้น คุณอาจต้องการมาตรฐาน VC ที่ตรงกัน

• ในแง่ของการจัดเก็บข้อมูลไม่ได้ระบุการจัดเก็บข้อมูลของ DID สามารถจัดเก็บได้โดยตรงบนเครือข่ายสาธารณะหรือบนเครือข่ายข้อมูลแบบกระจายศูนย์ (เช่น Ceramic Network) และยังสามารถจัดเก็บโดยตรงสำหรับผู้ใช้เอง ข้อมูล ของโครงการชื่อโดเมน Storage เป็นแบบ on-chain ทั้งหมด

โดยรวมแล้ว ระบบ DIDs เป็นการออกแบบจากบนลงล่าง ครอบคลุมกว่า และมาตรฐานที่เข้ากันได้มากกว่า นอกจากนี้ยังมีอีกหลายโครงการที่ใช้เส้นทาง DID เพื่อระบุตัวตนดิจิทัล เช่น Ontology

อย่างไรก็ตาม เนื่องจาก DIDs ของผู้ใช้ไม่สามารถอ่านได้ จึงเป็นเรื่องยากที่จะกลายเป็น "ชื่อ Web3" ที่ผู้ใช้จดจำในชีวิตประจำวันในระยะยาว นอกจากนี้ ผู้ใช้สามารถมี DID ที่แตกต่างกันในวิธีการ DID ที่แตกต่างกัน ทำให้ DID อยู่ใน ในระยะยาว อาจเป็นวัตถุที่รวมโดยชื่อโดเมน ดังนั้น จึงเรียกได้ว่าเป็น นอกจากนี้ แม้ว่าในทางทฤษฎี DID จะเข้ากันได้ดีกับข้อมูลนอกเครือข่าย แต่การพิจารณาที่ไม่น่าสนใจ บริษัท Web2 ในปัจจุบันไม่ค่อยให้คำแนะนำที่เกี่ยวข้องตาม DID และวิธีการโปรโมต DID ก็เป็นปัญหาเช่นกัน

3.6 เครื่องมือจัดการข้อมูลประจำตัว: ข้อมูลระบุตัวตนทั้งเครือข่าย vs ข้อมูลระบุตัวตนบางส่วน

ลักษณะการรวมข้อมูลประจำตัวในเครื่องของ GameID และ DID ยังนำไปสู่ความคิดโดยรวมและการจัดการข้อมูลประจำตัวในท้องถิ่น:

หากผลิตภัณฑ์การจัดการข้อมูลระบุตัวตนของคุณไม่สามารถหรือไม่สามารถรวมผลิตภัณฑ์ข้อมูลระบุตัวตนดิจิทัลของเครือข่ายทั้งหมดของผู้ใช้ได้ กล่าวคือ ผลิตภัณฑ์ดังกล่าวไม่ได้กลายเป็น "ชื่อ Web3" ของผู้ใช้ ดังนั้น เนื่องจากความสามารถในการทำงานร่วมกันของข้อมูลในห่วงโซ่ ID ของคุณจึงอาจกลายเป็นส่วนหนึ่ง ของข้อเสนอการจัดการตัวตนที่ใหญ่ขึ้น ตัวอย่างเช่น GameID ขนาดเล็กถูกรวมโดย GameID ขนาดใหญ่ GameID จะถูกรวมโดยโดเมน .eth และแม้แต่โดเมน .eth ก็สามารถรวมเข้าด้วยกันโดยโดเมน .bnb DID ที่กล่าวถึงข้างต้นมีแนวโน้มที่จะกลายเป็น "ตัวตนบางส่วน" ประเภทนี้ในอนาคต แม้แต่ในระดับหนึ่ง ที่อยู่กระเป๋าเงินเดียวก็สามารถกล่าวได้ว่าเป็น "ตัวตนบางส่วน"

อย่างไรก็ตาม เครื่องมือจัดการข้อมูลระบุตัวตนภายในเครื่องก็มีประโยชน์เช่นกัน เนื่องจากสามารถสร้างฟังก์ชันเพิ่มเติมสำหรับสถานการณ์แอปพลิเคชันเฉพาะ ซึ่งเป็นสิ่งที่เครื่องมือจัดการข้อมูลประจำตัวทั่วทั้งเครือข่ายอาจไม่จำเป็นต้องทำ มิฉะนั้นเครื่องมือจะล้น ตัวอย่างเช่น ในแพลตฟอร์มการจัดการ GameID ผู้ใช้อาจสามารถผูกมิตรกับผู้เล่นที่มีอาชีพเวทมนตร์เดียวกันในเกม MMORPG เดียวกันตามข้อมูลที่แสดงโดย GameID อื่น แต่ถ้าโครงการกระเป๋าเงิน/ชื่อโดเมนจำเป็นต้องมีฟังก์ชันที่แบ่งย่อยหลายส่วน มันจะเพิ่มความซับซ้อนของผลิตภัณฑ์และเผชิญกับความท้าทายในการออกแบบผลิตภัณฑ์มากมาย

4. ภาพสะท้อนของรูปแบบการพัฒนาขั้นสุดท้ายของ DID ในอนาคต

ประการแรก ในอนาคตทุกคนจะมีตัวตนดิจิทัลที่ผูกพันอย่างลึกซึ้งกับชีวิตประจำวัน:

• แต่ละคนสามารถมี DID (ผ่าน PoP) ได้เพียงหนึ่งรายการเท่านั้น ซึ่งใช้ในเครือข่าย Web3 ทั้งหมด และอาจผูกมัดกับตัวตนจริงของผู้ใช้ผ่าน KYC และวิธีการอื่นๆ เพื่อให้โต้ตอบกับโลกนอกเครือข่ายได้ดีขึ้น

• ชื่อโดเมน Web3 เป็นตัวระบุเฉพาะของ DID นี้ ซึ่งเป็นชื่อของผู้ใช้ใน Web3

• ผู้ใช้จัดการ DID นี้ผ่านกระเป๋าเงินที่มีฟังก์ชันที่มีประสิทธิภาพมากกว่าปัจจุบันมาก ภายในกระเป๋าเงิน โปรโตคอลการรวมข้อมูลประจำตัวหลายรายการอาจถูกรวมเข้าไว้ด้วยกันเพื่อรับรู้การรวมข้อมูลของที่อยู่หลายที่อยู่และหลายสัญญาของผู้ใช้ และแสดงข้อมูลของผู้ใช้อย่างครอบคลุม สถานะในแต่ละเครือข่าย ข้อมูลประจำตัวในแต่ละที่อยู่ ข้อมูลประจำตัวบางส่วน กราฟความสัมพันธ์ ฯลฯ เป็นภาพผู้ใช้ทั้งหมด

• ผู้ใช้โต้ตอบกับสถานการณ์ของแอปพลิเคชัน เช่น เครือข่ายสังคม การรับสมัคร และการกำกับดูแล DAO ผ่านกระเป๋าเงิน ด้วยเทคโนโลยีการเข้ารหัส ผู้ใช้สามารถควบคุมอำนาจของฝ่ายโครงการได้อย่างอิสระเพื่อรับข้อมูล เพื่อที่จะตระหนักว่าอำนาจอธิปไตยของข้อมูลเป็นของผู้ใช้

ประการที่สอง แต่ละคนมีตัวตนดิจิทัลที่แตกต่างกันหลายตัวในบางสถานการณ์ในท้องถิ่น (เช่น แพลตฟอร์มเกม) หรือบางสถานการณ์ที่ไม่จำเป็นต้องใช้ PoP เพื่อให้พวกเขาสามารถแสดงตัวตนที่แตกต่างกันในสถานการณ์ต่างๆ ได้ ผู้ใช้สามารถควบคุมการเชื่อมต่อระหว่างข้อมูลประจำตัวเหล่านี้ได้อย่างอิสระ และใช้ข้อมูลประจำตัวที่สอดคล้องกันในสถานการณ์เฉพาะ

V. บทสรุปของบทความที่แล้ว

จากการผสมผสานข้างต้น ฉันหวังว่าเมื่อผู้อ่านเห็นโครงการที่พูดถึงเรื่องเล่าที่เกี่ยวข้องกับ DID ในอนาคต พวกเขาจะทราบได้อย่างชัดเจนว่า "DID" นี้หมายถึง "อัตลักษณ์ที่กระจายอำนาจ" ประเภทใด: มันกำลังพูดถึงประเภทของ The การเปิดตัวข้อมูลประจำตัวเฉพาะยังคงพูดถึงกระบวนการรวมข้อมูลประจำตัวต่างๆ เข้ากับข้อมูลประจำตัว หรือกำลังพูดถึงการจัดการข้อมูลประจำตัวโดยผู้ใช้ หรือกำลังพูดถึงสถานการณ์แอปพลิเคชันเฉพาะของระบบข้อมูลประจำตัวนี้

เป็นเรื่องที่ควรค่าแก่การกล่าวถึงว่าโปรเจ็กต์ที่เกี่ยวข้องกับ DID มักมีเลเยอร์มากกว่าหนึ่ง ตัวอย่างเช่น Next.ID ที่วิเคราะห์ก่อนหน้านี้ไม่เพียงแต่ทำการโต้ตอบข้อมูลประจำตัวฝั่งผู้ใช้ เช่น ชื่อโดเมน แต่ยังดำเนินการรวมข้อมูลประจำตัว เช่น โปรโตคอลข้อมูลประจำตัวต่างๆ ARCx ไม่เพียงแต่เตรียมออกใบรับรองการให้คะแนนเครดิตเท่านั้น แต่ยังรวมถึงแอปพลิเคชันที่เกี่ยวข้องด้วย

รูปภาพด้านล่างเป็นการเรียงลำดับแทร็กที่เกี่ยวข้องกับ DID ดังที่ส่วนท้ายของบทความที่แล้ว

ถัดไป: คำถามสามข้อของ DID Soul

ในบทความหน้า ผู้เขียนจะอธิบายความคิดและความเข้าใจบางส่วนของเขาเกี่ยวกับสาขา DID ผ่านคำถามสามข้อ:

• ใครกันแน่ที่ต้องการ DID ตอนนี้?

• เหตุใด DID จึงยังอยู่ในช่วงเริ่มต้นและพัฒนาช้า

• ไม่ติดตามฉันควรลงคะแนนอย่างไร

1. DID ตอนนี้เป็นที่ต้องการของใคร?

1.1 DID ไม่ใช่ความต้องการของผู้ใช้ในขณะนี้

ผู้อ่านหลายคนอาจค้นพบว่าในหลาย ๆ กรณี DID นั้นไม่ใช่ความต้องการโดยตรงของผู้ใช้! จากมุมมองของผู้จัดการผลิตภัณฑ์ หากต้องการให้ DID มุ่งเน้นไปที่ผู้ใช้ ก็มักจะต้องผ่านสถานการณ์การใช้งานเฉพาะ

ลองจินตนาการดูว่า หากคุณไม่มีข้อกำหนดของแอปพลิเคชันเฉพาะในตอนนี้ แสดงว่าคุณสนใจที่จะขอรับข้อมูลรับรองต่างๆ (เช่น ไปที่ BrightID สำหรับการยืนยันใบหน้าด้วยวิดีโอ) หรือไปที่เครื่องมือการรวมข้อมูล/การจัดการข้อมูลประจำตัว (เช่น Next.id) เพื่อใส่ของคุณเอง ที่อยู่อีเมล Twitter และกระเป๋าเงินเชื่อมต่อกันทั้งหมดหรือไม่ ฉันเชื่อว่าผู้ใช้ส่วนใหญ่จะไม่

แม้ว่าฝ่ายโครงการจะให้สิ่งจูงใจบางอย่าง แน่นอนว่าจะสามารถดึงดูดผู้ใช้บางส่วนได้ แต่ลักษณะเฉพาะของผลิตภัณฑ์ DID ระบุว่าเป็นการยากที่จะทำให้การรักษาผู้ใช้อย่างต่อเนื่องด้วยสิ่งจูงใจนี้เพียงอย่างเดียว ซึ่งแตกต่างจากประเภทอื่น ๆ ของ โครงการต่างๆ เช่น NFT และ GameFi

ในระยะยาว ด้วยการปรับปรุงอย่างค่อยเป็นค่อยไปของการพัฒนา DID ผู้ใช้จะตระหนักถึงการจัดการและการใช้ข้อมูลประจำตัวส่วนบุคคลมากขึ้นเรื่อยๆ ดังนั้นอาจมีบางสถานการณ์ที่ความจำเป็นในการจัดการข้อมูลประจำตัวมาก่อนสถานการณ์แอปพลิเคชันเฉพาะ แต่นั่นไม่น่าจะเกิดขึ้นในขณะนี้เนื่องจากแทร็ก DID ยังอยู่ในช่วงเริ่มต้น

1.2 DID เป็นข้อกำหนดของฝ่ายโครงการสถานการณ์จำลองของแอปพลิเคชัน

ในความเป็นจริง เป็นฝ่ายโครงการของสถานการณ์แอปพลิเคชันเฉพาะที่ได้รับประโยชน์มากกว่าจาก DID ไม่ว่าจะเป็นการคัดกรองอย่างรวดเร็วตามข้อมูลรับรองหรือการรับภาพผู้ใช้อย่างรวดเร็วใน Web3 จะนำประโยชน์โดยตรงมาสู่ฝั่งโครงการในระยะเริ่มเย็น

อย่างไรก็ตาม เมื่อสถานการณ์จำลองของแอปพลิเคชันใช้ DID จริงและสร้าง DID ขึ้นมา ไม่จำเป็นต้องเน้นแนวคิดของ DID กับผู้ใช้ แนวคิดนี้จะถูกสรุปไว้ในตรรกะของผลิตภัณฑ์ ดังนั้นจึงไม่น่าแปลกใจที่แนวคิดของ DID ปรากฏในเรื่องเล่าและการอภิปรายโครงการบ่อยกว่าในสถานการณ์การใช้งานเฉพาะ

2. เหตุใดแทร็ก DID จึงยังอยู่ในช่วงเริ่มต้นและพัฒนาอย่างช้าๆ

เป็นความจริงที่ยอมรับได้ว่าแนวคิดของ DID สามารถย้อนไปถึงยุค Web2 และได้รับความนิยมตั้งแต่การออก ENS ในเดือนพฤศจิกายนปีที่แล้ว แต่ตอนนี้ แนวทาง DID ยังอยู่ในช่วงเริ่มต้น แม้ว่าจะมีหลายโครงการที่เกี่ยวข้องกับ DID แต่รูปแบบของ DID นั้นยังไม่ได้กำหนด และไม่มีร่องรอยของผลกระทบของเครือข่ายในการสะสมข้อมูลของระบบ DID ใดๆ

หลังจากชี้แจงว่าการพัฒนา DID นั้นต้องการสถานการณ์แอปพลิเคชันเฉพาะ ก็ไม่ยากที่จะเข้าใจปัญหานี้: สิ่งนี้เกี่ยวข้องกับ "การพัฒนาทางการเงินขั้นสูง" ในปัจจุบันของการพัฒนา Web3 และการพัฒนาช้าของโครงการ Web3 ที่ไม่ใช่ทางการเงิน เมื่อเราดูสถานการณ์การใช้งานที่เกี่ยวข้องกับการเล่าเรื่อง DID เราจะพบว่าโครงการ Web3 ที่ไม่ใช่ทางการเงินเกือบทั้งหมดสามารถนำเสนอการเล่าเรื่อง DID ได้

ดังนั้น เพื่อตอบคำถามนี้ สิ่งสำคัญคือต้องตอบว่าทำไมการพัฒนาแทร็กที่เกี่ยวข้องกับแต่ละสถานการณ์ของแอปพลิเคชัน Web3 ที่เกี่ยวข้องกับ DID จึงช้า

2.1 เหตุผลสามประการที่ทำให้การพัฒนาแอปพลิเคชันที่ไม่ใช่ทางการเงินของ Web3 ช้าลง

ผู้เขียนเชื่อว่าตรรกะสามประการต่อไปนี้ใช้ได้กับการวิเคราะห์โครงการสถานการณ์แอปพลิเคชันที่ไม่ใช่ทางการเงินของ Web3 ทั้งหมด รวมถึงเครือข่ายสังคมออนไลน์ เกม การสรรหาบุคลากร ฯลฯ (รายการที่มีคุณสมบัติเครื่องมือบางส่วนเช่นกระเป๋าเงินอยู่นอกเหนือขอบเขตของการสนทนา)

• ประสบการณ์ผู้ใช้ของแอปพลิเคชัน Web3 นั้นห่างไกลจากประสบการณ์ของแอปพลิเคชัน Web2 ที่สอดคล้องกัน ไม่ว่าจะเป็นเกณฑ์การใช้งานผลิตภัณฑ์ ความล่าช้าของเครือข่าย หรือค่าใช้จ่ายในการดำเนินการ ทั้งหมดนี้สูงกว่า Web2

• ฐานผู้ใช้ของแอปพลิเคชัน Web3 มีขนาดเล็กกว่า Web2 มากและกระจายอยู่ทั่วโลก สิ่งนี้ไม่เพียงแต่เป็นอุปสรรคต่อการเชื่อมต่อระหว่างโลกแห่งความจริงและโลกออนไลน์เท่านั้น แต่ยังทำให้เกิดความยุ่งยากมากขึ้นในการสะสมของผลกระทบเครือข่าย

• ขณะนี้อยู่ในวงจรตลาดหมี ผู้ใช้จำนวนมากสูญเสียสินทรัพย์และความถี่ของกิจกรรมในเครือข่ายลดลง ผู้ใช้บางคนถึงกับเริ่มสงสัยในอุตสาหกรรมทั้งหมดเหมือนในปี 2561 และ "ออกจากแวดวง" โดยตรง สิ่งนี้ทำให้ เริ่มโครงการแอปพลิเคชัน Web3 ได้ยากขึ้น

แต่ละรายการข้างต้นอาจเป็นเหตุผลสำคัญที่ทำให้โครงการสถานการณ์จำลองแอปพลิเคชัน Web3 พัฒนาได้ยาก หมายความว่าโครงการแอปพลิเคชัน Web3 ไม่มีโอกาสในการพัฒนาใช่หรือไม่ ไม่เชิง. ในบางสถานการณ์ที่ Web3 เป็นแบบเนทีฟและ Web2 ไม่สามารถทำได้ แม้ว่าจะมีปัญหาข้างต้นอยู่ ผลิตภัณฑ์ที่เกี่ยวข้องยังคงแสดงค่าของมันได้

2.2 การให้สินเชื่อแก่ C เป็นเรื่องเท็จในระยะสั้นถึงระยะกลาง

(สินเชื่อเครดิตของ To B เกี่ยวข้องกับตรรกะของ CeFi มากกว่า ดังนั้นในที่นี้เราจะพูดถึงสินเชื่อเครดิตของ To C เป็นหลัก)

การให้สินเชื่อเป็นสถานการณ์แอปพลิเคชันทางการเงินที่สำคัญที่สุดของ DID นี่เป็นหัวข้อที่เกิดขึ้นบ่อยครั้ง เนื่องจาก DeFis ที่มีอยู่เกือบทั้งหมดมีหลักทรัพย์ค้ำประกันมากเกินไปและมีประสิทธิภาพการใช้เงินทุนต่ำ ในทางทฤษฎี สินเชื่อเครดิตสามารถปรับปรุงประสิทธิภาพการใช้เงินทุนของผู้ใช้ และผู้ใช้ Web3 ก็จะมีความต้องการอย่างมากสำหรับเรื่องนี้

อย่างไรก็ตาม ผู้เขียนเชื่อว่าการให้สินเชื่อ To C เป็นเรื่องเท็จในระยะสั้นถึงระยะกลาง (เช่น ภายในสามปี) หรือเป็นช่องเฉพาะมาก

เหตุผลหลักคือโลกของ Web3 ไม่มีกลไกการไล่เบี้ยสำหรับเงินกู้ที่ไม่ชำระคืนเช่น Web2 ดังนั้น ต้นทุนสูงสุดของการไม่ชำระคืนเงินกู้คือการสูญเสียความพร้อมใช้งานของชุดข้อมูลประจำตัวบนเครือข่าย

บางคนอาจบอกว่าตัวตนดิจิทัลเองก็มีค่าเช่นกัน และคุณอาจไม่ต้องการละทิ้งที่อยู่ ชื่อโดเมน และข้อมูลประจำตัวอื่นๆ ที่คุณใช้มานานหลายปี รวมถึงการสั่งสมข้อมูลประจำตัวและข้อมูลเชิงสัมพันธ์ต่างๆ ข้างต้น แต่คำถามก็คือ ถามตัวเองว่า ข้อมูลประจำตัวบนเครือข่ายของผู้ใช้ Web3 ส่วนใหญ่ในปัจจุบันมีค่าเท่าใด หากคุณสามารถ "สินเชื่อเครดิต" ได้ 100U จะมีผู้ใช้กี่คนที่คิดว่าจะไม่จ่ายเงินคืนและอยากจะสร้างตัวตนของพวกเขาใหม่ เว้นแต่เกณฑ์การพิจารณาสินเชื่อจะสูงมาก สิ่งนี้จะทำให้เป็นผลิตภัณฑ์เฉพาะกลุ่มอย่างยิ่ง

บางคนอาจบอกว่าถ้าคุณทำ KYC และจดจำใบหน้า คุณอาจหลีกเลี่ยงปัญหานี้ได้ อย่างไรก็ตาม ในความเป็นจริงแล้ว ในพื้นที่ชนบทของประเทศด้อยพัฒนาต่างๆ นั้น ข้อมูลประจำตัวส่วนบุคคลที่ไร้ค่ามีอยู่มากมาย ลองนึกถึงข้อมูลที่คุณเห็นทุกวัน เช่น "บัญชี KYC ของการแลกเปลี่ยนถูกขายเป็นชุด" ตราบใดที่ "วงเงิน" สูงกว่าต้นทุนการสร้างตัวตน จะมี "การดูแลบัญชีอย่างมืออาชีพ" " ผู้ใช้และการก่อสร้างชุดตรงตามความต้องการ เอกลักษณ์ แล้วปฏิเสธที่จะชำระคืนเงินกู้ และคว้าขนของฝ่ายโครงการ

การครบกำหนดของการให้สินเชื่อ To C อาจจำเป็นต้องรอให้ระบบ DID ทั้งหมดครบกำหนด: ในด้านหนึ่ง การสะสมใบรับรองมูลค่าสูงและความสัมพันธ์ของข้อมูลที่หลากหลาย ต้นทุนการสร้างข้อมูลประจำตัวดิจิทัลและเกณฑ์การให้ จะเพิ่มขึ้นเรื่อย ๆ ในแง่หนึ่ง ด้วยการรุกของการกำกับดูแลในประเทศต่าง ๆ สินเชื่อ Web3 อาจสร้างกลไกการขอความช่วยเหลือทางกฎหมายซึ่งจะเพิ่มต้นทุนของผู้ใช้ที่ไม่ชำระคืนเงินกู้

3. ตรรกะของการลงทุนระดับการติดตามของ DID คืออะไร?

ที่นี่ ผู้เขียนแบ่งปันความคิดส่วนตัวบางประการเกี่ยวกับการลงทุนโดยรวมในระดับการติดตาม DID:

• ตรรกะโดยรวม: เริ่มจากผู้ใช้ แอปพลิเคชันนำหน้าข้อตกลง

• ลำดับความสำคัญเฉพาะ: การจัดการข้อมูลประจำตัว > สถานการณ์แอปพลิเคชัน > การออกหนังสือรับรอง > โปรโตคอลการรวมข้อมูลประจำตัว (ไม่ใช่ผู้ใช้)

3.1 ตรรกะโดยรวม: เริ่มจากผู้ใช้ แอปพลิเคชันนำหน้าโปรโตคอล

"แอปพลิเคชัน" ในที่นี้คือแนวคิดกว้างๆ ของ "ผู้ใช้เป็นหลัก" รวมถึงสถานการณ์เฉพาะ การจัดการข้อมูลประจำตัว และ "โปรโตคอล" สำหรับการออกหนังสือรับรอง โดยทั่วไปหมายถึงผลิตภัณฑ์โปรโตคอลต่างๆ ที่ไม่ได้มุ่งเน้นไปที่ผู้ใช้โดยตรง พวกเขามักจะให้บริการใน รูปแบบของการเรียก API ฝ่ายโครงการแอปพลิเคชันหรือข้อตกลงอื่นๆ

มีฝ่ายโครงการข้อตกลงบางฝ่ายที่อาจคิดเช่นนี้: ในฐานะข้อตกลง ฉันจะชักชวนฝ่ายโครงการแอปพลิเคชันเพิ่มเติมให้เข้าร่วมข้อตกลงของฉันต่อไป แอปพลิเคชันเหล่านี้ส่วนใหญ่อาจมีอายุสั้น และบางส่วนอาจพัฒนาได้ดี แต่ใน ในกรณีใด ๆ ข้อมูลของฉันสะสม และมีอุปสรรคด้านข้อมูลและผลกระทบของเครือข่าย ด้วยวิธีนี้ มูลค่าของฉันจะสูงขึ้นเรื่อย ๆ และโครงการเลเยอร์แอปพลิเคชันจะมาหาฉันเพื่อร่วมมือมากขึ้นเรื่อย ๆ ในที่สุดฉันก็สามารถเรียกเก็บเงินสำหรับ API หรือให้บริการเสริมที่เกี่ยวข้อง เป็นความจริงที่ว่าตรรกะข้างต้นสมเหตุสมผลและเป็นไปได้

แต่ผู้เขียนชอบสมัครเป็นอันดับแรกด้วยเหตุผลดังต่อไปนี้:

• ประการแรก ในทิศทางการไหลของข้อมูล แอปพลิเคชันต้องนำหน้าโพรโทคอล ดังนั้นจะมีความคิดริเริ่มที่ดีกว่า การถกเถียงระหว่างโปรโตคอลกับแอปพลิเคชันอาจดูเหมือน "ไก่กับไข่" เมื่อมองแวบแรก แต่ไม่ใช่ ตามที่กล่าวไว้ข้างต้น การสะสมของข้อมูล DID ขึ้นอยู่กับการโต้ตอบของผู้ใช้ในสถานการณ์เฉพาะของแอปพลิเคชัน

• ประการที่สอง สิ่งที่ฝั่งโครงการโปรโตคอลอาจยังไม่บรรลุนิติภาวะและยังอยู่ในขั้นตอนแนวคิด/การทดสอบ แม้ว่าจะบรรลุนิติภาวะแล้ว ก็อาจไม่สามารถตอบสนองความต้องการของฝั่งโครงการแอปพลิเคชันได้เป็นอย่างดี แทนที่จะให้ข้อเสนอแนะแก่ฝ่ายโปรโตคอลและคาดหวังให้มีการทำซ้ำ ด้านแอปพลิเคชันควรทำด้วยตัวเอง

• จากมุมมองที่สมจริงยิ่งขึ้น อุปสรรคด้านข้อมูลและเอฟเฟกต์เครือข่ายคือเรื่องเล่าที่ยอดเยี่ยมซึ่งผ่านการตรวจสอบโดย Web2 แล้ว ในขั้นตอนตัวอ่อนของการพัฒนาแทร็ก ของมูลค่านี้ปล่อยให้เป็นข้อตกลงของฝ่ายโครงการอื่น ๆ อย่างสมบูรณ์

• ท้ายที่สุด การจัดหาเงินทุนสำหรับโปรเจกต์แอปพลิเคชัน Web3 ในปัจจุบันนั้นยากมาก เหตุใดฝ่ายโปรเจกต์แอปพลิเคชันจึงไม่พูดถึงการเล่าเรื่อง DID ที่เกี่ยวข้องกับโปรโตคอลเพื่อสนับสนุนการประเมินมูลค่า ตัวอย่างเช่น ดึงดูดผู้ใช้ให้เข้าร่วมและสะสมข้อมูลผ่านตัวแอปพลิเคชันก่อน จากนั้นจึงจัดโปรโตคอลข้อมูลของผู้ใช้ในแอปพลิเคชันเพื่อใช้งานโดยพันธมิตรและระบบนิเวศที่เกี่ยวข้อง ซึ่งจะเป็นการรวบรวมข้อมูลเพิ่มเติมและพัฒนาไปสู่ระบบ DID ในที่สุด เรื่องเล่านี้สมเหตุสมผลหลายครั้ง

• นอกจากนี้ โปรโตคอล DID ส่วนใหญ่ไม่มีอุปสรรคทางเทคนิค และอุปสรรคดังกล่าวสะท้อนให้เห็นในระดับหนึ่งของความซับซ้อนทางวิศวกรรม สำหรับทีมที่ยอดเยี่ยม การพัฒนาโปรโตคอลด้วยตนเองตั้งแต่เริ่มต้นนั้นไม่ใช่เรื่องยาก แม้ว่าโครงการแอปพลิเคชัน เพื่อทำซ้ำผลิตภัณฑ์อย่างรวดเร็วจะใช้โปรโตคอลอื่น ๆ หากแอปพลิเคชันสามารถบรรลุผลสำเร็จฝ่ายโครงการอาจพิจารณาโปรโตคอลที่พัฒนาขึ้นเองเพื่อเพิ่มเพดานการพัฒนาของโครงการ

3.2 แทร็กย่อยเฉพาะที่ควรค่าแก่การเอาใจใส่

• ลำดับความสำคัญ: การจัดการข้อมูลประจำตัว > สถานการณ์แอปพลิเคชัน ≈ การเผยแพร่ข้อมูลรับรอง > (ไม่ใช่ผู้ใช้) โปรโตคอลการรวมข้อมูลประจำตัว

• โครงการเครื่องมือการจัดการข้อมูลประจำตัว: โครงการกระเป๋าเงินและชื่อโดเมนเป็นที่ต้องการ ท้ายที่สุดแล้ว ในความคิดของผู้เขียนในอนาคตเกี่ยวกับรูปแบบที่ดีที่สุดของ DID ทั้งคู่มีตำแหน่งหลักมาก

• โปรเจกต์ของสถานการณ์แอ็พพลิเคชัน: ดังที่ได้กล่าวไว้ก่อนหน้านี้ มีโอกาสมากขึ้นที่ปรากฏในข้อกำหนดแอ็พพลิเคชันดั้งเดิมของ Web3 มากกว่าการทำซ้ำของผลิตภัณฑ์ Web2 การรับสมัคร Web3 ตามข้อมูลประจำตัว, สังคมความสนใจตาม NFT/สังคมรักต่างเพศ ฯลฯ ล้วนอยู่ในสถานการณ์ Web3 ที่ไม่สามารถถูกแทนที่ได้นี้

• ลิงค์ต้นฉบับ

ลิงค์ต้นฉบับ