ขอขอบคุณเป็นพิเศษสำหรับ Liraz Siri, Yoav Weiss และผู้พัฒนา ImToken, Metamask และ OKX สำหรับคำติชมและบทวิจารณ์
ชั้นที่สำคัญของโครงสร้างพื้นฐาน Ethereum ที่มักถูกประเมินต่ำเกินไปโดยนักวิจัยและนักพัฒนา L1 หลักคือกระเป๋าเงิน กระเป๋าเงินเป็นหน้าต่างระหว่างผู้ใช้กับโลกของ Ethereum และผู้ใช้สามารถได้รับประโยชน์จากการกระจายอำนาจ การต่อต้านการเซ็นเซอร์ ความปลอดภัย ความเป็นส่วนตัว หรือคุณสมบัติอื่น ๆ ที่เสนอโดย Ethereum และแอปพลิเคชันเท่านั้น หากกระเป๋าเงินนั้นมีคุณสมบัติเหล่านั้นด้วย
เมื่อเร็วๆ นี้ เราได้เห็นกระเป๋าเงิน Ethereum มีความก้าวหน้าอย่างมากในการปรับปรุงประสบการณ์ผู้ใช้ ความปลอดภัย และฟังก์ชันการทำงาน วัตถุประสงค์ของบทความนี้คือเพื่อให้ความเห็นของตัวเองเกี่ยวกับคุณสมบัติบางอย่างที่กระเป๋าเงิน Ethereum ในอุดมคติควรมี นี่ไม่ใช่รายการที่ครอบคลุม มันสะท้อนถึงความโน้มเอียงทางไซเบอร์พังค์ของฉัน มันมุ่งเน้นไปที่ความปลอดภัยและความเป็นส่วนตัว และเกือบจะไม่สมบูรณ์อย่างแน่นอนในแง่ของประสบการณ์ผู้ใช้ อย่างไรก็ตาม ฉันไม่คิดว่าสิ่งที่ปรารถนาจะมีประสิทธิภาพในการเพิ่มประสิทธิภาพประสบการณ์ผู้ใช้ได้เท่ากับการปรับใช้และทำซ้ำตามคำติชม ดังนั้นฉันคิดว่าการมุ่งเน้นไปที่คุณลักษณะด้านความปลอดภัยและความเป็นส่วนตัวเป็นสิ่งที่มีค่าที่สุด
ประสบการณ์ผู้ใช้สำหรับธุรกรรมข้าม L2
ขณะนี้มีแผนงานที่มีรายละเอียดมากขึ้นสำหรับการปรับปรุงประสบการณ์ผู้ใช้ทั่วทั้ง L2 โดยมีส่วนในระยะสั้นและระยะยาว ผมจะพูดถึงส่วนระยะสั้นในที่นี้: แนวคิดที่ยังคงสามารถนำมาใช้ได้ในทางทฤษฎีแม้กระทั่งทุกวันนี้
แนวคิดหลักคือ (i) การส่งข้าม L2 ในตัว และ (ii) ที่อยู่เฉพาะของเครือข่ายและคำขอการชำระเงิน กระเป๋าเงินของคุณควรให้ที่อยู่แก่คุณได้ (ตามสไตล์ของ ร่าง ERC นี้ ) เช่นนี้:
เมื่อมีคน (หรือแอปพลิเคชันบางส่วน) ให้ที่อยู่แก่คุณในรูปแบบนี้ คุณควรจะสามารถวางที่อยู่นั้นลงในช่อง ถึง ของกระเป๋าเงินของคุณได้ และคลิก ส่ง กระเป๋าเงินควรจัดการข้อมูลที่ส่งโดยอัตโนมัติด้วยวิธีที่เป็นไปได้:
หากคุณมีโทเค็นประเภทที่ต้องการบนเชนเป้าหมายเพียงพอแล้ว ให้ส่งโทเค็นโดยตรง
หากคุณมีโทเค็นประเภทที่ต้องการบนเชนอื่น (หรือเชนอื่น ๆ หลายเชน) ให้ส่งโทเค็นโดยใช้โปรโตคอลเช่น ERC-7683 (จริงๆ แล้วเป็น cross-chain DEX)
หากคุณมีโทเค็นประเภทต่างๆ ในเครือข่ายเดียวกันหรือเครือข่ายอื่นๆ ให้ใช้การแลกเปลี่ยนแบบกระจายอำนาจเพื่อแปลงให้เป็นสกุลเงินประเภทที่ถูกต้องในเครือข่ายที่ถูกต้องและส่งไป สิ่งนี้ควรต้องได้รับอนุญาตอย่างชัดเจนจากผู้ใช้: ผู้ใช้จะเห็นจำนวนเงินที่พวกเขาจ่ายและจำนวนเงินที่ผู้รับได้รับ
รูปแบบของอินเทอร์เฟซกระเป๋าเงินที่เป็นไปได้พร้อมการรองรับที่อยู่แบบข้ามสายโซ่
ข้อมูลข้างต้นมีไว้สำหรับกรณีการใช้งาน คุณคัดลอกวางที่อยู่ (หรือ ENS เช่น vitalik.eth @optimism.eth ) และมีคนจ่ายเงินให้คุณ หาก dapp ร้องขอการฝากเงิน (เช่น ดู ตัวอย่าง Polymarket นี้ ) ขั้นตอนที่เหมาะสมที่สุดคือการขยาย web3 API และอนุญาตให้ dapp ส่งคำขอการชำระเงินเฉพาะลูกโซ่ กระเป๋าเงินของคุณจะสามารถปฏิบัติตามคำขอได้ทุกวิถีทางที่จำเป็น เพื่อประสบการณ์ผู้ใช้ที่ดี คำขอ getAvailableBalance จำเป็นต้องมีมาตรฐานด้วย และกระเป๋าสตางค์จำเป็นต้องพิจารณาอย่างรอบคอบว่าสินทรัพย์ผู้ใช้ในเครือข่ายใดจะถูกจัดเก็บไว้ในค่าเริ่มต้นเพื่อเพิ่มความปลอดภัยสูงสุดและความสะดวกในการโอน
คำขอชำระเงินเฉพาะเครือข่ายสามารถใส่ลงในรหัส QR ซึ่งสามารถสแกนด้วยกระเป๋าเงินมือถือได้ ในสถานการณ์การชำระเงินผู้บริโภคด้วยตนเอง (หรือออนไลน์) ผู้รับจะออกรหัส QR หรือการเรียก web3 API โดยแจ้งว่า ฉันต้องการโทเค็น X หน่วย Y Z บนลูกโซ่ พร้อมรหัสอ้างอิงหรือโทรกลับ W และกระเป๋าเงินจะสามารถ อย่าลังเลที่จะปฏิบัติตามคำร้องขอนี้ในทางใดทางหนึ่ง อีกทางเลือกหนึ่งคือโปรโตคอลการเชื่อมโยงการอ้างสิทธิ์ โดยที่กระเป๋าเงินของผู้ใช้สร้างรหัส QR หรือ URL ที่มีการอนุญาตการอ้างสิทธิ์เพื่อรับเงินจำนวนหนึ่งจากสัญญาออนไลน์ของตน และเป็นหน้าที่ของผู้รับที่จะหาวิธีโอนเงินเหล่านั้น ให้กับตัวเองในกระเป๋าสตางค์
อีกหัวข้อที่เกี่ยวข้องคือการชำระค่าน้ำมัน หากคุณได้รับสินทรัพย์บน L2 ที่ยังไม่มี ETH และจำเป็นต้องส่งธุรกรรมบน L2 นั้น กระเป๋าเงินควรจะสามารถใช้โปรโตคอลได้โดยอัตโนมัติ (เช่น RIP-7755 ) เพื่อชำระค่าก๊าซออนไลน์ ที่ที่คุณมี ETH หากกระเป๋าเงินต้องการให้คุณทำธุรกรรมเพิ่มเติมกับ L2 ในอนาคต ก็ควรส่งโดยใช้ DEX เท่านั้น ETH มูลค่าไม่กี่ล้าน Gas เพื่อให้การทำธุรกรรมในอนาคตสามารถใช้ Gas ที่นั่นได้โดยตรง (เพราะราคาถูกกว่า)
ความปลอดภัยของบัญชี
วิธีหนึ่งที่ฉันกำหนดแนวคิดเกี่ยวกับความท้าทายด้านความปลอดภัยของบัญชีคือกระเป๋าเงินที่ดีควรทำสองสิ่งพร้อมกัน: (i) ปกป้องผู้ใช้จากการแฮ็กหรือการโจมตีที่เป็นอันตรายโดยนักพัฒนากระเป๋าเงิน และ (ii) ปกป้องผู้ใช้จากการได้รับผลกระทบจากความผิดพลาดของคุณเอง
“ข้อผิดพลาด” ทางด้านซ้ายคือไม่ได้ตั้งใจ อย่างไรก็ตาม เมื่อฉันเห็นมัน ฉันพบว่ามันเข้ากับบริบทได้อย่างสมบูรณ์แบบ ดังนั้นฉันจึงตัดสินใจเก็บไว้
โซลูชันที่ฉันชอบสำหรับเรื่องนี้มา นานกว่า ทศวรรษ คือการฟื้นฟูทางสังคมและกระเป๋าเงินหลายลายเซ็นพร้อมการควบคุมการเข้าถึงแบบลำดับชั้น บัญชีผู้ใช้มีคีย์สองระดับ: คีย์หลักและผู้พิทักษ์ N (เช่น N = 5) คีย์หลักสามารถดำเนินการที่มีมูลค่าต่ำและไม่ใช่ทางการเงินได้ ผู้ปกครองส่วนใหญ่จำเป็นต้องดำเนินการ (i) การดำเนินการที่มีมูลค่าสูง เช่น การส่งมูลค่าทั้งหมดในบัญชี หรือ (ii) การเปลี่ยนคีย์หลักหรือผู้ปกครองใดๆ หากต้องการ คุณสามารถอนุญาตให้คีย์หลักดำเนินการที่มีมูลค่าสูงผ่านการล็อคเวลาได้
ข้างต้นเป็นการออกแบบขั้นพื้นฐานและสามารถขยายได้ กลไกการอนุญาต เช่น คีย์เซสชันและ ERC-7715 สามารถช่วยสนับสนุนความสมดุลของความสะดวกสบายและความปลอดภัยที่แตกต่างกันสำหรับแอปพลิเคชันที่แตกต่างกัน สถาปัตยกรรมผู้พิทักษ์ที่ซับซ้อนยิ่งขึ้น เช่น การมีระยะเวลาล็อคเวลาหลายครั้งตามเกณฑ์ที่ต่างกัน สามารถช่วยเพิ่มโอกาสสูงสุดในการกู้คืนบัญชีที่ถูกกฎหมายได้สำเร็จ ในขณะเดียวกันก็ลดความเสี่ยงของการโจรกรรมด้วย
ข้างต้นเป็นการออกแบบขั้นพื้นฐานและสามารถขยายได้ กลไกการอนุญาต เช่น คีย์เซสชันและ ERC-7715 สามารถช่วยสนับสนุนความสมดุลของความสะดวกสบายและความปลอดภัยที่แตกต่างกันสำหรับแอปพลิเคชันที่แตกต่างกัน สถาปัตยกรรมผู้พิทักษ์ที่ซับซ้อนมากขึ้น เช่น การมีระยะเวลาล็อคเวลาหลายครั้งตามเกณฑ์ที่ต่างกัน สามารถช่วยเพิ่มโอกาสสูงสุดในการกู้คืนบัญชีที่ถูกกฎหมายได้สำเร็จ ในขณะเดียวกันก็ลดความเสี่ยงของการโจรกรรมด้วย
ผู้ปกครองควรเป็นใครหรืออะไร?
ตัวเลือกที่เป็นไปได้สำหรับผู้ใช้ crypto ที่มีประสบการณ์ในชุมชนผู้ใช้ crypto ที่มีประสบการณ์คือกุญแจของเพื่อนและครอบครัวของคุณ หากคุณขอให้ทุกคนให้ที่อยู่ใหม่แก่คุณ ก็ไม่มีใครจำเป็นต้องรู้ว่าพวกเขาเป็นใคร ที่จริงแล้ว ผู้ปกครองของคุณไม่จำเป็นต้องรู้ว่าอีกฝ่ายเป็นใครด้วยซ้ำ หากพวกเขาไม่ได้แจ้งให้คุณทราบ โอกาสที่พวกเขาจะสมรู้ร่วมคิดก็มีน้อยมาก อย่างไรก็ตาม สำหรับผู้ใช้ใหม่ส่วนใหญ่ ตัวเลือกนี้จะไม่สามารถใช้ได้
ตัวเลือกที่สองคือผู้ดูแลสถาบัน: บริษัทที่เชี่ยวชาญในการให้บริการที่ลงนามในธุรกรรมเมื่อพวกเขาได้รับการยืนยันคำขอเพิ่มเติมของคุณเพิ่มเติม: เช่น รหัสยืนยันหรือแฮงเอาท์วิดีโอสำหรับผู้ใช้ที่มีมูลค่าสูง ผู้คนพยายามสร้างสิ่งเหล่านี้มานานแล้ว ฉันประวัติ CryptoCorp ในปี 2013 อย่างไรก็ตาม บริษัทเหล่านี้ยังไม่ประสบความสำเร็จมากนักจนถึงขณะนี้
ตัวเลือกที่สามคืออุปกรณ์ส่วนตัวหลายเครื่อง (เช่น โทรศัพท์ เดสก์ท็อป กระเป๋าเงินฮาร์ดแวร์) วิธีนี้ได้ผล แต่ก็เป็นเรื่องยากสำหรับผู้ใช้ที่ไม่มีประสบการณ์ในการตั้งค่าและจัดการ ยังมีความเสี่ยงที่อุปกรณ์จะสูญหายหรือถูกขโมยในเวลาเดียวกัน โดยเฉพาะอย่างยิ่งหากอุปกรณ์เหล่านั้นอยู่ในสถานที่เดียวกัน
เมื่อเร็วๆ นี้ เราเริ่มเห็นโซลูชันที่ใช้คีย์หลักมากขึ้น สามารถสำรองข้อมูลคีย์ได้บนอุปกรณ์ของคุณเท่านั้น ทำให้เป็นโซลูชันอุปกรณ์ส่วนบุคคล หรือในระบบคลาวด์ ทำให้การรักษาความปลอดภัยขึ้นอยู่กับการผสมผสาน ที่ซับซ้อน ของการรักษาความปลอดภัยด้วยการเข้ารหัส อำนาจ และสมมติฐานด้านฮาร์ดแวร์ที่เชื่อถือได้ อันที่จริง คีย์เป็นการเพิ่มความปลอดภัยที่มีคุณค่าสำหรับผู้ใช้โดยเฉลี่ย แต่เพียงอย่างเดียวไม่เพียงพอที่จะปกป้องการช่วยชีวิตของผู้ใช้
โชคดีที่มี ZK-SNARK เรามีทางเลือกที่สี่: ID แบบรวมศูนย์ของแพ็คเกจ ZK ประเภทนี้รวมถึง zk-email , Anon Aadhaar , Myna Wallet เป็นต้น โดยพื้นฐานแล้ว คุณจะใช้ ID แบบรวมศูนย์ในรูปแบบใดก็ได้ (องค์กรหรือหน่วยงานราชการ) และแปลงเป็นที่อยู่ Ethereum และคุณสามารถส่งธุรกรรมได้โดยการสร้าง ZK-SNARK ที่พิสูจน์ว่าคุณมี ID แบบรวมศูนย์เท่านั้น
ด้วยการเพิ่มนี้ ตอนนี้เรามีตัวเลือกมากมายและ “ความเป็นมิตรกับมือใหม่” ที่เป็นเอกลักษณ์ของ ID แบบรวมศูนย์ที่ห่อด้วย ZK
ในการดำเนินการนี้ จะต้องดำเนินการผ่าน UI ที่เรียบง่ายและบูรณาการ: คุณควรระบุได้เฉพาะที่คุณต้องการให้ example@gmail.com เป็นผู้ปกครอง และควรสร้างที่อยู่ zk-email Ethereum ที่เกี่ยวข้องโดยอัตโนมัติภายใต้ เครื่องดูดควัน ผู้ใช้ขั้นสูงควรสามารถป้อนอีเมลของตน (และอาจเป็นเกลือความเป็นส่วนตัวที่บันทึกไว้ในอีเมลนั้น) ลงในแอปพลิเคชันบุคคลที่สามแบบโอเพ่นซอร์ส และยืนยันว่าที่อยู่ผลลัพธ์นั้นถูกต้อง เช่นเดียวกับผู้ปกครองประเภทอื่นๆ ที่ได้รับการสนับสนุน
โปรดทราบว่าความท้าทายในทางปฏิบัติที่ต้องเผชิญกับอีเมล zk ในปัจจุบันก็คือ ต้องใช้ลาย เซ็น DKIM ซึ่งใช้คีย์ที่หมุนเวียนทุกๆ สองสามเดือน และไม่ได้ลงนามโดยหน่วยงานอื่นใด ซึ่งหมายความว่า zk-email ในปัจจุบันมีข้อกำหนดด้านความน่าเชื่อถือในระดับหนึ่งนอกเหนือจากผู้ให้บริการเอง ซึ่งสามารถลดลงได้หาก zk-email ใช้ TLSNotary ภายในฮาร์ดแวร์ที่เชื่อถือได้เพื่อตรวจสอบคีย์ที่อัปเดต แต่ก็ไม่เหมาะ หวังว่าผู้ให้บริการอีเมลจะเริ่มลงนามคีย์ DKIM ของตนโดยตรง วันนี้ฉันขอแนะนำ zk-email สำหรับผู้ปกครองคนเดียว แต่ไม่ใช่สำหรับผู้ปกครองส่วนใหญ่: อย่าเก็บเงินไว้ในการตั้งค่าที่อีเมล zk ที่เสียหายหมายความว่าคุณไม่สามารถใช้เงินได้
ผู้ใช้ใหม่และกระเป๋าเงินในแอป
ผู้ใช้ใหม่ไม่ต้องการป้อนผู้ปกครองจำนวนมากเมื่อลงทะเบียนครั้งแรก ดังนั้นกระเป๋าเงินควรให้ตัวเลือกที่ง่ายมากแก่พวกเขา เส้นทางปกติคือทำ 2 ใน 3 โดยใช้อีเมล zk กับที่อยู่อีเมลของพวกเขา คีย์ที่จัดเก็บไว้ในอุปกรณ์ของผู้ใช้ (อาจเป็นคีย์หลัก) และคีย์สำรองที่ผู้ให้บริการเลือก เมื่อผู้ใช้มีประสบการณ์มากขึ้นหรือสะสมทรัพย์สินมากขึ้น ในบางจุดพวกเขาควรได้รับแจ้งให้เพิ่มผู้ปกครองเพิ่มเติม
การรวม Wallet เข้ากับแอปเป็นสิ่งที่หลีกเลี่ยงไม่ได้ เนื่องจากแอปที่พยายามดึงดูดผู้ใช้ที่ไม่ใช่ Crypto ไม่ต้องการให้ผู้ใช้ได้รับประสบการณ์ที่สับสนในการดาวน์โหลดแอปใหม่ 2 แอป (ตัวแอปเองและกระเป๋าเงิน Ethereum) ในเวลาเดียวกัน อย่างไรก็ตาม ผู้ใช้ Wallet ของแอปจำนวนมากควรจะสามารถเชื่อมโยง Wallet ทั้งหมดของตนเข้าด้วยกันได้ เพื่อให้พวกเขามี ปัญหาการควบคุมการเข้าถึง เพียงปัญหาเดียวเท่านั้นที่ต้องกังวล วิธีที่ง่ายที่สุดคือการใช้โครงร่างแบบเป็นชั้นซึ่งมีกระบวนการ เชื่อมโยง ที่รวดเร็วซึ่งช่วยให้ผู้ใช้สามารถตั้งค่ากระเป๋าเงินหลักของตนเป็นผู้พิทักษ์กระเป๋าเงินในแอปทั้งหมดได้ Warpcast ไคลเอนต์ Farcaster รองรับสิ่งนี้แล้ว:
ตามค่าเริ่มต้น การกู้คืนบัญชี Warpcast ของคุณจะถูกควบคุมโดยทีมงาน Warpcast อย่างไรก็ตาม คุณสามารถ ยึดครอง บัญชี Farcaster ของคุณและเปลี่ยนการกู้คืนเป็นที่อยู่ของคุณเองได้
ปกป้องผู้ใช้จากการหลอกลวงและภัยคุกคามภายนอกอื่นๆ
นอกเหนือจากการรักษาความปลอดภัยของบัญชีแล้ว กระเป๋าเงินในปัจจุบันยังทำหน้าที่หลายอย่างในการระบุที่อยู่ปลอม ฟิชชิ่ง สแกม และภัยคุกคามภายนอกอื่น ๆ และพยายามปกป้องผู้ใช้จากภัยคุกคามดังกล่าว ในขณะเดียวกัน มาตรการรับมือหลายอย่างยังคงค่อนข้างดั้งเดิม เช่น กำหนดให้ต้องคลิกเพื่อส่ง ETH หรือโทเค็นอื่น ๆ ไปยังที่อยู่ใหม่ ไม่ว่าคุณจะส่งเงิน $100 หรือ $100,000 ที่นี่ไม่มีกระสุนวิเศษแม้แต่นัดเดียว นี่เป็นชุดการแก้ไขและปรับปรุงที่ช้าและต่อเนื่องสำหรับภัยคุกคามประเภทต่างๆ อย่างไรก็ตาม การปรับปรุงอย่างต่อเนื่องที่นี่มีประโยชน์มาก
ความเป็นส่วนตัว
ถึงเวลาที่จะเริ่มให้ความสำคัญกับความเป็นส่วนตัวบน Ethereum อย่างจริงจังมากขึ้น ขณะนี้เทคโนโลยี ZK-SNARK ก้าวหน้าไปมาก เทคโนโลยีความเป็นส่วนตัวที่ไม่ต้องใช้แบ็คดอร์เพื่อลดความเสี่ยงด้านกฎระเบียบ (เช่น พูลความเป็นส่วนตัว ) กำลังมีความสมบูรณ์มากขึ้น และโครงสร้างพื้นฐานรอง เช่น Waku และ ERC-4337 mempool จะค่อยๆ มีเสถียรภาพมากขึ้น อย่างไรก็ตาม จนถึงขณะนี้ การโอนย้ายแบบส่วนตัวบน Ethereum กำหนดให้ผู้ใช้ต้องดาวน์โหลดและใช้ กระเป๋าเงินส่วนตัว อย่างชัดเจน เช่น Railway (หรือ Umbra สำหรับ ที่อยู่ที่ซ่อนอยู่ ) สิ่งนี้จะเพิ่มความไม่สะดวกอย่างมากและลดจำนวนผู้ที่ยินดีทำการโอนเงินแบบส่วนตัว วิธีแก้ไขคือการโอนส่วนตัวจำเป็นต้องรวมเข้ากับกระเป๋าเงินโดยตรง
การใช้งานอย่างง่ายมีดังนี้ Wallets สามารถจัดเก็บทรัพย์สินส่วนหนึ่งของผู้ใช้เป็น ยอดเงินส่วนตัว ในกลุ่มความเป็นส่วนตัว เมื่อผู้ใช้ทำการโอน พวกเขาจะออกจากกลุ่มความเป็นส่วนตัวก่อนโดยอัตโนมัติ หากผู้ใช้ต้องการรับเงิน กระเป๋าเงินจะสามารถสร้างที่อยู่ที่ซ่อนตัวได้โดยอัตโนมัติ
นอกจากนี้ กระเป๋าเงินสามารถสร้างที่อยู่ใหม่โดยอัตโนมัติสำหรับแต่ละแอปพลิเคชันที่ผู้ใช้เข้าร่วม (เช่น โปรโตคอล defi) การฝากเงินจะมาจากกลุ่มความเป็นส่วนตัวและการถอนเงินจะไปที่กลุ่มความเป็นส่วนตัวโดยตรง ซึ่งจะทำให้กิจกรรมของผู้ใช้ในแอปใดแอปหนึ่งสามารถยกเลิกการเชื่อมโยงจากกิจกรรมในแอปอื่นได้
ข้อดีอย่างหนึ่งของเทคโนโลยีนี้คือ มันเป็นเส้นทางธรรมชาติที่ไม่เพียงแต่สำหรับการถ่ายโอนสินทรัพย์ที่รักษาความเป็นส่วนตัวเท่านั้น แต่ยังรวมถึงข้อมูลประจำตัวที่รักษาความเป็นส่วนตัวด้วย ข้อมูลระบุตัวตนเกิดขึ้นบนเครือข่ายแล้ว: แอปพลิเคชันใดๆ ที่ใช้การตรวจสอบข้อมูลระบุตัวตน (เช่น Gitcoin Grants), แชทที่มีโทเค็นควบคุม, Ethereum ตามโปรโตคอล ฯลฯ ถือเป็นข้อมูลประจำตัวออนไลน์ เราต้องการให้ระบบนิเวศนี้ปกป้องความเป็นส่วนตัวเช่นกัน ซึ่งหมายความว่าไม่ควรรวบรวมกิจกรรมออนไลน์ของผู้ใช้ไว้ในที่เดียว แต่ละโครงการควรจัดเก็บแยกกัน และกระเป๋าเงินของผู้ใช้ควรเป็นสิ่งเดียวที่มี มุมมองทั่วโลก ที่สามารถดูหลักฐานทั้งหมดของคุณในเวลาเดียวกัน . ระบบนิเวศดั้งเดิมของหลายบัญชีต่อผู้ใช้แต่ละรายช่วยให้บรรลุเป้าหมายนี้ได้ เช่นเดียวกับโปรโตคอลป้องกันนอกเครือข่าย เช่น EAS และ Zupass
สิ่งนี้แสดงถึงวิสัยทัศน์เชิงปฏิบัติสำหรับความเป็นส่วนตัวของ Ethereum ในระยะกลาง แม้ว่าคุณสมบัติบางอย่างสามารถนำมาใช้ได้ที่ L1 และ L2 เพื่อทำให้การส่งข้อมูลแบบรักษาความเป็นส่วนตัวมีประสิทธิภาพและความน่าเชื่อถือมากขึ้น แต่สามารถใช้งานได้ทันที ผู้สนับสนุนความเป็นส่วนตัวบางคนเชื่อว่าสิ่งเดียวที่ยอมรับได้คือความเป็นส่วนตัวของทุกสิ่งโดยสมบูรณ์: เข้ารหัส EVM ทั้งหมด ฉันคิดว่านี่อาจเป็นผลลัพธ์ในระยะยาวในอุดมคติ แต่จะต้องมีการคิดใหม่เกี่ยวกับรูปแบบการเขียนโปรแกรมขั้นพื้นฐานมากขึ้นและยังไม่ถึงระดับวุฒิภาวะที่พร้อมที่จะปรับใช้บน Ethereum เราต้องการความเป็นส่วนตัวเป็นค่าเริ่มต้นเพื่อให้ได้ชุดข้อมูลที่ไม่เปิดเผยตัวตนที่เพียงพอ อย่างไรก็ตาม การมุ่งเน้นไปที่ (i) การถ่ายโอนระหว่างบัญชีเป็นอันดับแรก และ (ii) กรณีการใช้งานที่เกี่ยวข้องกับข้อมูลประจำตัวและข้อมูลประจำตัว (เช่น การพิสูจน์ส่วนตัว) ถือเป็นขั้นตอนแรกในทางปฏิบัติที่ง่ายต่อการนำไปใช้ และกระเป๋าเงินสามารถเริ่มใช้งานได้ทันที
กระเป๋าเงิน Ethereum ก็ต้องเป็นกระเป๋าข้อมูลด้วย
ผลลัพธ์ประการหนึ่งของโซลูชันความเป็นส่วนตัวที่มีประสิทธิภาพ ไม่ว่าจะเป็นการชำระเงิน การระบุตัวตน หรือกรณีการใช้งานอื่นๆ ก็คือ ทำให้ผู้ใช้จำเป็นต้องจัดเก็บข้อมูลของตนแบบออฟไลน์ สิ่งนี้เห็นได้ชัดใน Tornado Cash ซึ่งกำหนดให้ผู้ใช้บันทึก ตั๋ว ซึ่งแต่ละใบคิดเป็นเงินฝาก 0.1-100 ETH โปรโตคอลความเป็นส่วนตัวที่ทันสมัยกว่าบางครั้งจะเก็บข้อมูลที่เข้ารหัสไว้แบบออนไลน์และใช้คีย์ส่วนตัวเพียงอันเดียวเพื่อถอดรหัส สิ่งนี้มีความเสี่ยงเพราะหากคีย์รั่วไหลหรือคอมพิวเตอร์ควอนตัมเป็นไปได้ ข้อมูลทั้งหมดจะถูกเปิดเผยต่อสาธารณะ การพิสูจน์แบบออฟไลน์ เช่น EAS และ Zupass มีความต้องการการจัดเก็บข้อมูลแบบออฟไลน์ที่ชัดเจนยิ่งขึ้น
กระเป๋าเงินจะต้องเป็นซอฟต์แวร์ที่ไม่เพียงแต่เก็บสิทธิ์การเข้าถึงออนไลน์เท่านั้น แต่ยังรวมถึงข้อมูลส่วนตัวของคุณด้วย โลกที่ไม่ใช่สกุลเงินดิจิทัลก็กำลังตระหนักถึงสิ่งนี้มากขึ้นเช่นกัน ดู ผลงานล่าสุดของ Tim Berners-Lee เกี่ยวกับการจัดเก็บข้อมูลส่วนบุคคล ปัญหาทั้งหมดที่เราต้องแก้ไขอย่างเข้มงวดเพื่อให้มั่นใจในการควบคุมการเข้าถึง เรายังต้องแก้ไขอย่างเข้มงวดเพื่อให้แน่ใจว่าข้อมูลสามารถเข้าถึงได้และไม่รั่วไหล บางทีวิธีแก้ปัญหาเหล่านี้อาจซ้อนกันได้: หากคุณมีผู้ปกครอง N คน ให้ใช้การแบ่งปันความลับ M-of-N ระหว่างผู้ปกครอง N เหล่านั้นเพื่อจัดเก็บข้อมูลของคุณ ข้อมูลนั้นยากต่อการปกป้องโดยธรรมชาติ เนื่องจากคุณไม่สามารถเพิกถอนการแบ่งปันข้อมูลของผู้อื่นได้ แต่เราควรใช้โซลูชันโฮสติ้งแบบกระจายอำนาจที่ปลอดภัยที่สุดเท่าที่จะเป็นไปได้
การเข้าถึงห่วงโซ่ที่ปลอดภัย
ปัจจุบัน Wallet ไว้วางใจผู้ให้บริการ RPC ของตนในการแจ้งข้อมูลใดๆ เกี่ยวกับห่วงโซ่ดังกล่าว นี่เป็นช่องโหว่ในสองวิธี:
ผู้ให้บริการ RPC อาจพยายามขโมยเงินโดยให้ข้อมูลเท็จแก่พวกเขา เป็นต้น เกี่ยวกับราคาตลาด.
ผู้ให้บริการ RPC สามารถดึงข้อมูลส่วนตัวเกี่ยวกับแอปพลิเคชันและบัญชีอื่นๆ ที่ผู้ใช้โต้ตอบด้วยได้
ตามหลักการแล้ว เราต้องการปิดช่องโหว่ทั้งสองนี้ ในการแก้ปัญหาแรก เราต้องการไคลเอ็นต์ light ที่ได้มาตรฐานสำหรับ L1 และ L2 ที่สามารถตรวจสอบฉันทามติบล็อคเชนได้โดยตรง Helios ทำสิ่งนี้กับ L1 แล้ว และได้ทำงานเบื้องต้นเพื่อรองรับ L2 บางรุ่นโดยเฉพาะ เพื่อให้ครอบคลุม L2 ทั้งหมดอย่างเหมาะสม เราจำเป็นต้องมีมาตรฐานที่สัญญาการกำหนดค่าที่เป็นตัวแทนของ L2 (และใช้สำหรับที่อยู่เฉพาะลูกโซ่ด้วย) สามารถประกาศฟังก์ชันได้ ซึ่งอาจในลักษณะเดียวกันกับ ERC-3668 ที่มีฟังก์ชันการรับค่าที่ใกล้ที่สุด ระบุสถานะและตรวจสอบสถานะลอจิคัลของใบรับรองและใบเสร็จรับเงินเทียบกับรากของสถานะเหล่านั้น ด้วยวิธีนี้เราสามารถมีไคลเอนต์ light สากลที่ช่วยให้กระเป๋าเงินสามารถตรวจสอบสถานะหรือเหตุการณ์ใด ๆ บน L1 และ L2 ได้อย่างปลอดภัย
เพื่อความเป็นส่วนตัว แนวทางเดียวที่สมจริงในปัจจุบันคือการรันโหนดเต็มรูปแบบของคุณเอง อย่างไรก็ตาม เมื่อ L2 เข้ามาอยู่ในสายตาแล้ว การรันฟูลโหนดกับทุกสิ่งก็กลายเป็นเรื่องยากมากขึ้น สิ่งที่เทียบเท่ากับไคลเอ็นต์แบบเบาที่นี่คือ การเรียกค้นข้อมูลส่วนตัว (PIR) PIR เกี่ยวข้องกับเซิร์ฟเวอร์ที่เก็บสำเนาข้อมูลทั้งหมดและไคลเอนต์ที่ส่งคำขอที่เข้ารหัสไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์ทำการคำนวณข้อมูลทั้งหมด ส่งคืนข้อมูลที่ลูกค้าต้องการ เข้ารหัสไปยังคีย์ของไคลเอ็นต์ โดยไม่เปิดเผยต่อเซิร์ฟเวอร์ว่าข้อมูลชิ้นใดที่ไคลเอนต์เข้าถึง
เพื่อให้เซิร์ฟเวอร์มีความซื่อสัตย์ โครงการฐานข้อมูลแต่ละโครงการถือเป็น Merkle fork ดังนั้นลูกค้าจึงสามารถใช้ไคลเอ็นต์แบบ light เพื่อตรวจสอบได้
PIR (หมายเหตุ Deep Chao: โดยทั่วไปหมายถึง การดึงข้อมูลส่วนตัว (Private Information Retrieval) ซึ่งเป็นโปรโตคอลหรือเทคโนโลยีที่ช่วยให้ผู้ใช้สามารถดึงข้อมูลจากฐานข้อมูลโดยไม่ต้องเปิดเผยข้อมูลที่ดึงมา) ปริมาณการคำนวณมีขนาดใหญ่มาก มีหลายวิธีในการแก้ปัญหานี้:
ด้วยกำลังที่รุนแรง: การปรับปรุงอัลกอริธึมหรือฮาร์ดแวร์พิเศษอาจทำให้ PIR ทำงานเร็วเพียงพอ เทคนิคเหล่านี้อาจขึ้นอยู่กับการประมวลผลล่วงหน้า: เซิร์ฟเวอร์สามารถจัดเก็บข้อมูลที่เข้ารหัสและสัญญาณรบกวนสำหรับไคลเอนต์แต่ละราย และไคลเอนต์สามารถสืบค้นข้อมูลนั้นได้ ความท้าทายหลักในสภาพแวดล้อม Ethereum คือการปรับเทคโนโลยีเหล่านี้ให้เข้ากับชุดข้อมูลที่เปลี่ยนแปลงอย่างรวดเร็ว (เช่นเดียวกับประเทศต่างๆ) ทำให้การประมวลผลแบบเรียลไทม์ถูกลง แต่อาจทำให้ต้นทุนการประมวลผลและพื้นที่เก็บข้อมูลทั้งหมดสูงขึ้น
ข้อกำหนดความเป็นส่วนตัวที่อ่อนแอลง: ตัวอย่างเช่น สามารถมี มิกซ์อิน ได้เพียง 1 ล้านรายการต่อการค้นหา ดังนั้นเซิร์ฟเวอร์จะทราบค่าที่เป็นไปได้ 1 ล้านค่าที่ลูกค้าสามารถเข้าถึงได้ แต่ไม่มีรายละเอียดปลีกย่อยใด ๆ
PIR หลายเซิร์ฟเวอร์: หากคุณใช้เซิร์ฟเวอร์หลายเครื่อง และความซื่อสัตย์ระหว่างเซิร์ฟเวอร์เหล่านี้ถือเป็น 1-of-N ดังนั้นอัลกอริทึม PIR มักจะเร็วกว่า
การไม่เปิดเผยตัวตนแทนการรักษาความลับ: คำขอสามารถส่งผ่านเครือข่ายไฮบริด โดยซ่อนผู้ส่งคำขอแทนที่จะซ่อนเนื้อหาของคำขอ อย่างไรก็ตาม การดำเนินการดังกล่าวอย่างมีประสิทธิภาพจะช่วยเพิ่มเวลาแฝงอย่างหลีกเลี่ยงไม่ได้ ซึ่งจะทำให้ประสบการณ์ผู้ใช้แย่ลง
การค้นหาการผสมผสานเทคโนโลยีที่เหมาะสมเพื่อเพิ่มความเป็นส่วนตัวในขณะที่ยังคงใช้งานได้จริงในสภาพแวดล้อม Ethereum นั้นเป็นคำถามวิจัยที่เปิดกว้าง และฉันยินดีต้อนรับนักเข้ารหัสให้ลองทำเช่นนั้น
กระเป๋าเก็บกุญแจในอุดมคติ
นอกเหนือจากการขนส่งและการเข้าถึงสถานะแล้ว ขั้นตอนการทำงานที่สำคัญอีกประการหนึ่งที่ต้องทำงานได้อย่างราบรื่นในบริบท L2 คือการเปลี่ยนการกำหนดค่าการรับรองความถูกต้องของบัญชี ไม่ว่าจะเป็นการเปลี่ยนคีย์ (เช่น การกู้คืน) หรือทำการเปลี่ยนแปลงเชิงลึกในตรรกะทั้งหมดของ บัญชี เปลี่ยน มีวิธีแก้ปัญหาสามระดับที่นี่ ตามลำดับความยากที่เพิ่มขึ้น:
อัปเดตการเล่นซ้ำ: เมื่อผู้ใช้เปลี่ยนการกำหนดค่า ข้อความที่อนุญาตการเปลี่ยนแปลงนี้จะถูกเล่นซ้ำในทุกห่วงโซ่ที่กระเป๋าเงินตรวจพบว่าผู้ใช้เป็นเจ้าของทรัพย์สิน รูปแบบข้อความและกฎการตรวจสอบอาจเป็นแบบลูกโซ่อิสระ ดังนั้นจึงเล่นซ้ำโดยอัตโนมัติบนลูกโซ่มากที่สุดเท่าที่จะเป็นไปได้
ที่เก็บคีย์บน L1: ข้อมูลการกำหนดค่าอยู่บน L1 กระเป๋าเงินบน L2 อ่านโดยใช้ L1S LOAD หรือ การเรียกแบบคงที่ระยะไกล ด้วยวิธีนี้ คุณเพียงแค่ต้องอัปเดตการกำหนดค่าบน L1 เท่านั้น และการกำหนดค่าจะมีผลโดยอัตโนมัติ
ที่เก็บคีย์บน L2: ข้อมูลการกำหนดค่ามีอยู่บน L2 และกระเป๋าเงินบน L2 ใช้ ZK-SNARK เพื่ออ่าน สิ่งนี้เหมือนกับ (2) ยกเว้นว่าการอัปเดตที่เก็บคีย์อาจมีราคาถูกกว่า แต่ในทางกลับกัน การอ่านจะมีราคาแพงกว่า
โซลูชัน (3) มีประสิทธิภาพเป็นพิเศษเนื่องจากเล่นได้ดีกับความเป็นส่วนตัว ใน วิธีแก้ปัญหาความเป็นส่วนตัว ปกติ ผู้ใช้จะมีความลับ s เผยแพร่ ค่าลีฟ L บนเชน และผู้ใช้พิสูจน์ว่า L = hash(s, 1) และ N = hash(s, 2) สำหรับบางส่วน (s, 2) พวกเขาควบคุมความลับที่ไม่เคยเปิดเผย) มีการออก N ที่ทำให้ใช้ไม่ได้เพื่อให้แน่ใจว่าการจ่ายเงินในอนาคตของ Leaf เดียวกันจะล้มเหลวโดยไม่เปิดเผย L ซึ่งขึ้นอยู่กับความปลอดภัยของผู้ใช้ โซลูชันความเป็นส่วนตัวที่เป็นมิตรต่อการกู้คืนจะกล่าวว่า: s คือตำแหน่ง (เช่น ที่อยู่และช่องเก็บข้อมูล) บนเครือข่าย และผู้ใช้จะต้องพิสูจน์ข้อความค้นหาสถานะ: L = hash(sload(s), 1)
การรักษาความปลอดภัย DAPP
ลิงค์ที่อ่อนแอที่สุดในความปลอดภัยของผู้ใช้มักจะเป็น dapp โดยส่วนใหญ่แล้ว ผู้ใช้จะโต้ตอบกับแอปพลิเคชันโดยไปที่เว็บไซต์ ซึ่งจะดาวน์โหลดโค้ดส่วนต่อประสานกับผู้ใช้แบบเรียลไทม์จากเซิร์ฟเวอร์ จากนั้นจึงดำเนินการในเบราว์เซอร์ หากเซิร์ฟเวอร์ถูกแฮ็กหรือ DNS ถูกแฮ็ก ผู้ใช้จะได้รับสำเนาอินเทอร์เฟซปลอม ซึ่งสามารถหลอกให้พวกเขาดำเนินการตามอำเภอใจได้ ฟีเจอร์กระเป๋าสตางค์ เช่น การจำลองการซื้อขายมีประโยชน์อย่างมากในการลดความเสี่ยง แต่ก็ยังห่างไกลจากความสมบูรณ์แบบ
ตามหลักการแล้ว เราจะย้ายระบบนิเวศไปสู่การกำหนดเวอร์ชันเนื้อหาแบบออนไลน์: ผู้ใช้จะเข้าถึง dapp ผ่านชื่อ ENS ซึ่งจะมีแฮช IPFS ของอินเทอร์เฟซ การอัปเดตอินเทอร์เฟซจำเป็นต้องมีธุรกรรมออนไลน์จากหลายลายเซ็นหรือ DAO กระเป๋าเงินจะแสดงให้ผู้ใช้เห็นว่าพวกเขากำลังโต้ตอบกับอินเทอร์เฟซออนไลน์ที่ปลอดภัยกว่าหรืออินเทอร์เฟซ Web2 ที่มีความปลอดภัยน้อยกว่า Wallets ยังสามารถแสดงให้ผู้ใช้เห็นว่าพวกเขากำลังโต้ตอบกับห่วงโซ่ที่ปลอดภัยหรือไม่ (เช่น เฟส 1+ การตรวจสอบความปลอดภัยหลายรายการ)
สำหรับผู้ใช้ที่คำนึงถึงความเป็นส่วนตัว กระเป๋าเงินยังสามารถเพิ่มโหมดหวาดระแวง โดยกำหนดให้ผู้ใช้คลิกเพื่อยอมรับคำขอ HTTP ไม่ใช่แค่การทำงานของ web3:
รูปแบบอินเทอร์เฟซที่เป็นไปได้สำหรับโหมดหวาดระแวง
แนวทางขั้นสูงกว่านั้นคือการก้าวไปไกลกว่า HTML + Javascript และเขียนตรรกะทางธุรกิจของ dapp ในภาษาเฉพาะ (บางทีอาจเป็นการซ้อนทับที่ค่อนข้างบางบน Solidity หรือ Vyper) เบราว์เซอร์จะสามารถสร้าง UI สำหรับฟังก์ชันการทำงานที่ต้องการได้โดยอัตโนมัติ OKContract กำลังดำเนินการนี้อยู่แล้ว
อีกทิศทางหนึ่งคือการป้องกันข้อมูลเศรษฐกิจเข้ารหัส: นักพัฒนา dapp, บริษัทรักษาความปลอดภัย, chain Deployers และอื่น ๆ สามารถสร้างพันธะที่จะจ่ายให้กับผู้รับหาก dapp ถูกแฮ็กหรือทำร้ายผู้ใช้ในลักษณะที่ทำให้เข้าใจผิดอย่างมาก ผู้ใช้ที่ได้รับผลกระทบ (ระบุได้) ตัดสินโดย DAO ออนไลน์บางส่วน กระเป๋าเงินสามารถแสดงคะแนนให้กับผู้ใช้ตามขนาดของพันธบัตร
อนาคตระยะยาว
ทั้งหมดนี้อยู่ในบริบทของอินเทอร์เฟซแบบเดิม ซึ่งเกี่ยวข้องกับการชี้และการคลิกสิ่งต่างๆ และการพิมพ์สิ่งต่างๆ ลงในช่องข้อความ อย่างไรก็ตาม เรายังอยู่บนจุดสูงสุดของการเปลี่ยนแปลงกระบวนทัศน์ที่ลึกซึ้งยิ่งขึ้นอีกด้วย:
ปัญญาประดิษฐ์ซึ่งอาจนำเราจากกระบวนทัศน์แบบคลิกเพื่อพิมพ์ไปสู่กระบวนทัศน์ พูดในสิ่งที่คุณต้องการทำแล้วหุ่นยนต์จะคิดออก
อินเทอร์เฟซของคอมพิวเตอร์สมองมีตั้งแต่วิธีการ อ่อนโยน เช่น การติดตามดวงตา ไปจนถึงเทคโนโลยีที่ตรงและแม้กระทั่งรุกราน (ดู: ผู้ป่วย Neuralink รายแรกของปีนี้ )
การป้องกันเชิงรุกฝั่งไคลเอ็นต์: Brave Browser ปกป้องผู้ใช้ในเชิงรุกจากโฆษณา ตัวติดตาม และวัตถุที่ไม่ต้องการอื่น ๆ อีกมากมาย เบราว์เซอร์ ปลั๊กอิน และกระเป๋าเงินดิจิตอลจำนวนมากมีทั้งทีมงานที่ทำงานอย่างแข็งขันเพื่อปกป้องผู้ใช้จากภัยคุกคามด้านความปลอดภัยและความเป็นส่วนตัวต่างๆ “ผู้พิทักษ์เชิงบวก” เหล่านี้จะแข็งแกร่งขึ้นในทศวรรษหน้าเท่านั้น
แนวโน้มทั้งสามนี้จะนำไปสู่การคิดใหม่เกี่ยวกับวิธีการทำงานของอินเทอร์เฟซให้ลึกซึ้งยิ่งขึ้น ด้วยการป้อนข้อมูลด้วยภาษาธรรมชาติ การติดตามดวงตา หรืออินเทอร์เฟซคอมพิวเตอร์และสมองโดยตรงในที่สุด ควบคู่ไปกับประวัติของคุณ (อาจรวมถึงข้อความ ตราบใดที่ข้อมูลทั้งหมดได้รับการประมวลผลในเครื่อง) กระเป๋าเงิน สามารถเข้าใจได้อย่างชัดเจนและเป็นธรรมชาติว่าคุณต้องการไปที่ใด ไป. ทำ. จากนั้น AI ก็สามารถแปลสัญชาตญาณนี้ให้เป็น “แผนปฏิบัติการ” ที่เป็นรูปธรรม: ชุดของการโต้ตอบทั้งแบบออนไลน์และออฟไลน์เพื่อให้บรรลุสิ่งที่คุณต้องการ สิ่งนี้สามารถลดความจำเป็นในการใช้อินเทอร์เฟซผู้ใช้ของบุคคลที่สามได้อย่างมาก หากผู้ใช้โต้ตอบกับแอปพลิเคชันบุคคลที่สาม (หรือผู้ใช้รายอื่น) AI ควรคิดในทางตรงข้ามในนามของผู้ใช้ ระบุภัยคุกคามใด ๆ และแนะนำแผนปฏิบัติการเพื่อหลีกเลี่ยง ตามหลักการแล้ว AI เหล่านี้ควรมีระบบนิเวศแบบเปิด ผลิตโดยกลุ่มที่หลากหลายซึ่งมีอคติและโครงสร้างแรงจูงใจที่แตกต่างกัน
แนวคิดที่ต่างไปจากเดิมอย่างสิ้นเชิงเหล่านี้ขึ้นอยู่กับเทคโนโลยีที่ยังไม่บรรลุนิติภาวะมากในปัจจุบัน ดังนั้น ฉันจะไม่นำทรัพย์สินของฉันไปไว้ในกระเป๋าเงินที่พึ่งพาสิ่งเหล่านั้นในปัจจุบัน อย่างไรก็ตาม ดูเหมือนชัดเจนว่าบางสิ่งเช่นนี้เป็นหนทางแห่งอนาคต ดังนั้นจึงคุ้มค่าที่จะเริ่มสำรวจอย่างจริงจังมากขึ้นในทิศทางนี้
