สิ่งที่ฉันต้องการเห็นในกระเป๋าเงิน

กลาง12/10/2024, 4:23:35 AM
วิตาลิค บุตเตอรินพูดถึงกระเป๋าเก็บเงิน Ethereum ที่เหมาะสม โดยให้ความสำคัญกับคุณสมบัติสำคัญ เช่น การทำธุรกรรมข้าม Layer 2 การเพิ่มความปลอดภัยและการป้องกันความเป็นส่วนตัว เขาเน้นว่ากระเป๋าเงินสามารถจัดการธุรกรรม multi-chain และ cross-Layer 2 ได้อย่างราบรื่น ปรับปรุงประสบการณ์ผู้ใช้ และรองรับการเก็บรักษาข้อมูลและตัวตนแบบกระจาย นอกจากนี้ เขาย้ำความจำเป็นของการรวมฟีเจอร์ความเป็นส่วนตัว เช่น ZK-SNARKs สำหรับธุรกรรมส่วนตัว และการรักษาความปลอดภัยที่แข็งแกร่งเพื่อต่อต้านความเสี่ยงเช่นการโจมตีแฟชิง

ประสบการณ์ของผู้ใช้ในการทำธุรกรรมระหว่าง L2 ที่แตกต่างกัน

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

ไอเดียหลักคือ (i) การส่งข้าม L2 ที่ซ่อนอยู่ในตัว, และ (ii) ที่อยู่และคำขอการชำระเงินที่เฉพาะกับเครื่องหมายลายเซ็น. กระเป๋าเงินของคุณควรสามารถให้คุณที่อยู่ซึ่ง (ตามรูปแบบของ ร่างนี้ ERC) ดูเหมือนว่า

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

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

  • หากคุณมีเหรียญประเภทที่ต้องการเพียงพอในห่วงโซ่ปลายทางให้ส่งเหรียญโดยตรง
  • หากคุณมีเหรียญชนิดที่ต้องการบนโซ่อื่น ๆ (หรือหลายโซ่อื่น ๆ) ใช้โปรโตคอลเช่น gateERC-7683 (effectively a cross-chain DEX) เพื่อส่งเหรียญ
  • หากคุณมีเหรียญประเภทอื่น ๆ บนโซ่เดียวกันหรือโซ่อื่น ๆ ให้ใช้บัญชีศูนย์กลางเพื่อแปลงพวกเขาให้กลายเป็นประเภทของเหรียญที่เหมาะสมบนโซ่ที่เหมาะสมและส่งพวกเขา นี่ควรต้องการอนุญาตโดยชัดเจนจากผู้ใช้: ผู้ใช้จะเห็นว่าพวกเขาจ่ายเท่าไหร่และได้รับเท่าไหร่

ขอบเขตของอินเตอร์เฟซกระเป๋าเงินที่เป็นไปได้พร้อมการสนับสนุนที่อยู่跨ลึก

ข้างต้นเป็นสำหรับ "คุณคัดลอกและวางที่อยู่ (หรือ ENS, เช่น vitalik.eth@optimism.eth) สำหรับใครบางคนที่จะจ่ายให้คุณ" ใช้เคส หาก dapp กำลังขอฝาก (เช่น ดูตัวอย่าง Polymarket นี้) จากนั้นโฟลว์ในอุดมคติคือการขยาย web3 API และอนุญาตให้ dapp ส่งคําขอชําระเงินเฉพาะห่วงโซ่ กระเป๋าเงินของคุณจะสามารถตอบสนองคําขอนั้นได้ทุกวิถีทางที่ต้องการ การทําให้ประสบการณ์ของผู้ใช้ทํางานได้ดีจะต้องมีการกําหนดมาตรฐานคําขอ getAvailableBalance และกระเป๋าเงินจะต้องคิดให้มากว่าเครือข่ายใดที่พวกเขาจัดเก็บทรัพย์สินของผู้ใช้โดยค่าเริ่มต้นเพื่อเพิ่มความปลอดภัยและความสะดวกในการถ่ายโอน

คําขอชําระเงินเฉพาะห่วงโซ่สามารถใส่ลงในรหัส QR ซึ่งกระเป๋าเงินมือถือสามารถสแกนได้ ในสถานการณ์การชําระเงินของผู้บริโภคด้วยตนเอง (หรือออนไลน์) ผู้รับจะทํารหัส QR หรือการเรียก web3 API ที่ระบุว่า "ฉันต้องการ X หน่วยโทเค็น Y บน chain Z พร้อมรหัสอ้างอิงหรือการเรียกกลับ W" และกระเป๋าเงินจะมีอิสระที่จะตอบสนองคําขอนั้นในทุกวิถีทางที่สามารถทําได้ อีกทางเลือกหนึ่งคือโปรโตคอลลิงก์การอ้างสิทธิ์ซึ่งกระเป๋าเงินของผู้ใช้จะสร้างรหัส QR หรือ URL ที่มีการอนุญาตให้อ้างสิทธิ์เงินจํานวนหนึ่งจากสัญญา onchain ของพวกเขาและเป็นหน้าที่ของผู้รับที่จะหาวิธีย้ายเงินเหล่านั้นไปยังกระเป๋าเงินของตนเอง

หัวข้อที่เกี่ยวข้องอีกอย่างคือการชำระค่าแก๊ส หากคุณได้รับสินทรัพย์บน L2 ที่คุณยังไม่มี ETH และคุณต้องการส่งธุรกรรมบน L2 นั้น กระเป๋าสตางค์ควรสามารถใช้โปรโตคอลโดยอัตโนมัติ (เช่น RIP-7755) ในการชำระค่าแก๊สในเครือข่ายที่คุณมี ETH หากกระเป๋าเงินคาดหวังให้คุณทำธุรกรรมเพิ่มเติมบน L2 ในอนาคต ก็ควรใช้ DEX เพื่อส่งกลับเช่นเดียวกับ ETH มูลค่าก๊าซหลายล้านภายในเพื่อให้การทำธุรกรรมในอนาคตสามารถใช้ก๊าซได้โดยตรงที่นั่น (เนื่องจากมีราคาถูกกว่า)

ความปลอดภัยของบัญชี

วิธีหนึ่งที่ผมอธิบายความท้าทายด้านความปลอดภัยของบัญชีคือว่ากระเป๋าเงินที่ดีควรเป็นดีในสองด้านพร้อมกัน: (i) ป้องกันผู้ใช้ไม่ให้นักพัฒนากระเป๋าเงินถูกแฮ็กหรือทำให้เสียหาย, และ (ii) ป้องกันผู้ใช้ไม่ให้เกิดข้อผิดพลาดของตัวเอง

การพิมพ์ผิดคำว่า 'mistakles' ทางซ้ายเป็นความผิดพลาดที่ไม่ได้ตั้งใจ อย่างไรก็ตาม เมื่อเห็นมันฉันก็รู้สึกว่ามันเหมาะสมกับบริบท ดังนั้นฉันตัดสินใจเก็บไว้

วิธีที่ฉันชอบมากที่สุดสำหรับสะกดสิบปีมีการกู้คืนสังคมและกระเป๋าเงินมัลติซิกพร้อมควบคุมการเข้าถึงที่จัดเกรด บัญชีผู้ใช้มีสองชั้นของกุญแจ: กุญแจหลัก และ N ผู้พิทักษ์ (เช่น N = 5) กุญแจหลักสามารถดำเนินการที่มีค่าต่ำและไม่เกี่ยวกับการเงิน ต้องการผู้พิทักษ์ส่วนใหญ่เพื่อดำเนินการที่เป็นไปได้ทั้ง (i) ดำเนินการที่มีค่าสูง เช่น ส่งออกค่าทั้งหมดในบัญชี หรือ (ii) เปลี่ยนแปลงกุญแจหลักหรือผู้พิทักษ์ใดๆ ตามต้องการ กุญแจหลักสามารถทำการที่มีค่าสูงพร้อมกับการล็อคเวลา หากต้องการ

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

ใครหรืออะไรควรเป็นผู้คุ้มครอง?

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

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

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

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

โชคดีที่มี ZK-SNARKs เรามีทางเลือกที่สี่: ZK-wrapped centralized ID ประเภทนี้รวมถึงzk-email, Anon Aadhaar, กระเป๋าเงิน Myna, และอื่น ๆ พื้นฐานแล้วคุณสามารถใช้รูปแบบหลายรูปแบบของ ID ที่ถูก (บริษัทหรือรัฐบาล) จัดกลุ่ม และแปลงเป็นที่อยู่ Ethereum ซึ่งคุณสามารถส่งธุรกรรมได้เท่านั้นโดยการสร้างการพิสูจน์ ZK-SNARK ที่แสดงความเป็นเจ้าของของ ID ที่ถูกจัดกลุ่ม

ด้วยการเพิ่มนี้ตอนนี้เรามีตัวเลือกมากมายและ ID ส่วนกลางที่ห่อหุ้มด้วย ZK นั้น "เป็นมิตรกับ noob" โดยเฉพาะ

สำหรับการทำงานนี้ จะต้องนำมาใช้ร่วมกับ UI ที่ได้รับการรวมรวมและรวมร่างไว้: คุณควรสามารถระบุได้เพียงแค่ว่าคุณต้องการexample@gmail.comเป็นผู้ปกครอง และควรสร้างที่อยู่อีเธอเรียม zk-email ที่เกี่ยวข้องโดยอัตโนมัติภายใน ผู้ใช้ขั้นสูงควรสามารถป้อนอีเมลของพวกเขา (พร้อมกับค่าเกลือสำหรับความเป็นส่วนตัวบางอย่าง ซึ่งจะถูกบันทึกไว้ในอีเมลนั้น) เข้าสู่แอปพลิเคชั่นบุคคลสามที่เปิดออกและยืนยันว่าที่อยู่ที่สร้างขึ้นถูกต้อง สิ่งเดียวกันควรเป็นจริงสำหรับประเภทผู้ปกครองที่รองรับอื่น ๆ ทุกประการ

โมคัพของอินเตอร์เฟซที่เป็นไปได้

โปรดทราบว่าวันนี้ความท้าทายในทางปฏิบัติอย่างหนึ่งของ zk-email โดยเฉพาะคือมันขึ้นอยู่กับ ลายเซ็น DKIMซึ่งใช้คีย์ที่หมุนทุกๆ สองสามเดือน และคีย์เหล่านี้ไม่ได้ลงนามโดยหน่วยงานอื่นใด ซึ่งหมายความว่า zk-email ในปัจจุบันมีข้อกําหนดด้านความไว้วางใจในระดับหนึ่งนอกเหนือจากผู้ให้บริการเอง สิ่งนี้อาจลดลงได้หากใช้ ZK-email TLSNotaryสำหรับการยืนยันคีย์ DKIM ผมหวังว่าผู้ให้บริการอีเมลจะเริ่มเซ็นต์คีย์ DKIM ของพวกเขาโดยตรง วันนี้ผมขอแนะนำให้ใช้ zk-email สำหรับ Guardian คนเดียว แต่ไม่ใช่สำหรับ Guardian ส่วนใหญ่: อย่าเก็บเงินในระบบที่ zk-email ขัดข้องหมายถึงคุณสูญเสียการเข้าถึงเงินของคุณ

ผู้ใช้ใหม่และกระเป๋าเงินในแอป

ผู้ใช้ใหม่ในความเป็นจริงจะไม่ต้องการที่จะต้องป้อนจำนวนผู้ปกครองมากในประสบการณ์การสมัครครั้งแรกของพวกเขา ดังนั้นกระเป๋าเงินควรมีตัวเลือกที่ง่ายมากสำหรับพวกเขา หนึ่งเส้นทางธรรมชาติคือ 2-of-3 โดยใช้ zk-email บนที่อยู่อีเมลของพวกเขา คีย์ที่เก็บไว้ในอุปกรณ์ของผู้ใช้ (ซึ่งอาจเป็นรหัสผ่าน) และคีย์สำรองที่ถือโดยผู้ให้บริการ ในขณะที่ผู้ใช้เริ่มเชี่ยวชาญมากขึ้นหรือสะสมสินทรัพย์มากขึ้น ในบางจุดพวกเขาควรได้รับการเรียกให้เพิ่มผู้ปกครองเพิ่มเติม

กระเป๋าเงินที่รวมอยู่ในแอปพลิเคชันเป็นสิ่งที่หลีกเลี่ยงไม่ได้เนื่องจากแอปพลิเคชันที่พยายามดึงดูดผู้ใช้ที่ไม่ใช่ crypto ไม่ต้องการประสบการณ์การใช้งานที่สับสนในการขอให้ผู้ใช้ดาวน์โหลดแอปพลิเคชันใหม่สองรายการ (ตัวแอปเองรวมถึงกระเป๋าเงิน Ethereum) ในเวลาเดียวกัน อย่างไรก็ตามผู้ใช้กระเป๋าเงินแอปพลิเคชันจํานวนมากควรสามารถเชื่อมโยงกระเป๋าเงินทั้งหมดเข้าด้วยกันเพื่อให้พวกเขามี "สิ่งที่ควบคุมการเข้าถึง" เพียงสิ่งเดียวที่ต้องกังวล วิธีที่ง่ายที่สุดในการทําเช่นนี้คือรูปแบบลําดับชั้นซึ่งมีกระบวนการ "เชื่อมโยง" ที่รวดเร็วซึ่งช่วยให้ผู้ใช้สามารถตั้งค่ากระเป๋าเงินหลักให้เป็นผู้พิทักษ์กระเป๋าเงินในแอปทั้งหมดได้ ไคลเอนต์ Farcaster Warpcast รองรับสิ่งนี้แล้ว:

โดยค่าเริ่มต้นการกู้คืนบัญชี Warpcast ของคุณถูกควบคุมโดยทีม Warpcast อย่างไรก็ตามคุณสามารถ “เอาถิ่นสำหรับ” บัญชี Farcaster ของคุณ และเปลี่ยนการกู้คืนไปยังที่อยู่ของคุณเอง

การป้องกันผู้ใช้จากการโกงและอุปสรรคจากภายนอกอื่น ๆ

นอกจากความปลอดภัยของบัญชีแล้ว กระเป๋าเงินวันนี้ทำมากเพื่อระบุที่อยู่ปลอม การจ phishing โกหก และอุปกรณ์คุกคามอื่น ๆ และพยายามปกป้องผู้ใช้ของพวกเขาจากอันตรายเช่นนี้ ในเวลาเดียวกัน มีหลายวิธีที่ใช้สำหรับการต้านต่อยังคงค่อนข้างโดยรวม: เช่น การกำหนดค่าการคลิกเพื่อส่ง ETH หรือโทเคนใด ๆ ไปยังที่อยู่ใหม่ ๆ โดยไม่ว่าคุณจะส่ง $100 หรือ $100,000 ที่นี่ไม่มีทางแก้ไขแบบเดียวกัน; มันเป็นชุดของการแก้ไขที่รวดเร็วและการปรับปรุงต่อเนื่องในหมวดหมู่ต่าง ๆ ของอันตราย อย่างไรก็ตาม มีค่ามากในการทำงานหนักเพื่อปรับปรุงที่นี่

ความเป็นส่วนตัว

ตอนนี้เวลาที่จะเริ่มให้ความสำคัญกับความเป็นส่วนตัวบน Ethereum มากขึ้น เทคโนโลยี ZK-SNARK ได้ก้าวหน้ามาก เทคโนโลยีความเป็นส่วนตัวที่ช่วยลดความเสี่ยงทางกฎหมายโดยไม่ต้องพึ่งพาทางหลัง เช่น Privacy Poolsกำลังเติบโตและเจริญเติบโตมากขึ้นเรื่อย ๆ และพื้นฐานทางด้านระบบย่อยเช่น Wakuและ mempools ERC-4337 กำลังเริ่มทำให้เสถียรมากขึ้น อย่างไรก็ตาม จนถึงตอนนี้ การทำธุรกรรมเงินส่วนตัวบน Ethereum ต้องการผู้ใช้งานจะต้องดาวน์โหลดและใช้ "กระเป๋าเงินความเป็นส่วนตัว" เช่นรถไฟ (or Umbraสำหรับstealth addresses). นี้ทำให้มีความไม่สะดวกสำหรับผู้ที่ต้องการทำการโอนเงินส่วนตัวและลดจำนวนคนที่เต็มใจที่จะทำการโอนเงินส่วนตัว วิธีการแก้ไขคือการรวมการโอนเงินส่วนตัวเข้ากับกระเป๋าเงินโดยตรง

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

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

หนึ่งในข้อดีของเทคนิคนี้คือเป็นทางเลือกธรรมชาติที่สามารถทำให้การโอนทรัพย์สินที่คุ้มครองความเป็นส่วนตัวและบุคคลภาพที่คุ้มครองความเป็นส่วนตัวเกิดขึ้นได้ สิ่งที่เกิดขึ้นบนเชือกอยู่แล้ว: แอปพลิเคชันใด ๆ ที่ใช้การจัดการเป็นหลักฐานเพื่อความเป็นตัวตน (เช่น Gitcoin Grants) การสนทนาผ่านเชือกของโทเคน และ Ethereum ปฏิบัติตามโปรโตคอลและอื่น ๆ อีกมากมายล้วนเป็นอัตลักษณ์ของ onchain เราต้องการให้ระบบนิเวศนี้รักษาความเป็นส่วนตัวด้วย ซึ่งหมายความว่าไม่ควรรวบรวมกิจกรรมของผู้ใช้ในที่เดียว: แต่ละรายการควรจัดเก็บแยกต่างหากและกระเป๋าเงินของผู้ใช้ควรเป็นสิ่งเดียวที่มี "มุมมองส่วนกลาง" ที่เห็นการรับรองทั้งหมดของคุณในเวลาเดียวกัน ระบบนิเวศแบบหลายบัญชีต่อผู้ใช้ช่วยให้บรรลุเป้าหมายนี้เช่นเดียวกับโปรโตคอลการรับรอง offchain เช่น EASและZupass.

สิ่งนี้แสดงถึงวิสัยทัศน์ในทางปฏิบัติสําหรับความเป็นส่วนตัวของ Ethereum ในอนาคตระยะกลาง สามารถใช้งานได้ในปัจจุบันแม้ว่าจะมีคุณสมบัติที่สามารถแนะนําได้ที่ L1 และ L2 เพื่อให้การถ่ายโอนที่รักษาความเป็นส่วนตัวมีประสิทธิภาพและเชื่อถือได้มากขึ้น ผู้สนับสนุนความเป็นส่วนตัวบางคนยืนยันว่าสิ่งเดียวที่ยอมรับได้คือความเป็นส่วนตัวทั้งหมดของทุกสิ่ง: การเข้ารหัส EVM ทั้งหมด ฉันจะยืนยันว่านี่อาจเหมาะเป็นผลลัพธ์ระยะยาว แต่ต้องมีการทบทวนรูปแบบการเขียนโปรแกรมขั้นพื้นฐานมากขึ้นและขณะนี้ยังไม่ถึงระดับวุฒิภาวะที่พร้อมจะไปและปรับใช้ทั่วทั้ง Ethereum เราต้องการความเป็นส่วนตัวโดยค่าเริ่มต้นเพื่อให้ได้ชุดการไม่เปิดเผยตัวตนที่มีขนาดใหญ่เพียงพอ อย่างไรก็ตามการมุ่งเน้นไปที่ (i) การโอนระหว่างบัญชีและ (ii) กรณีการใช้งานข้อมูลประจําตัวและข้อมูลประจําตัวที่อยู่ติดกันเช่นการรับรองส่วนตัวเป็นขั้นตอนแรกในทางปฏิบัติที่ง่ายต่อการนําไปใช้และกระเป๋าเงินใดที่สามารถเริ่มต้นได้ในวันนี้

กระเป๋าเงิน Ethereum ต้องกลายเป็นกระเป๋าข้อมูลด้วย

ผลที่ตามมาอย่างหนึ่งของโซลูชันความเป็นส่วนตัวที่มีประสิทธิภาพไม่ว่าจะเป็นการชําระเงินหรือข้อมูลประจําตัวหรือกรณีการใช้งานอื่น ๆ คือมันสร้างความต้องการสําหรับผู้ใช้ในการจัดเก็บข้อมูล offchain สิ่งนี้ชัดเจนใน Tornado Cash ซึ่งกําหนดให้ผู้ใช้บันทึก "โน้ต" แต่ละรายการซึ่งแสดงถึงเงินฝาก 0.1-100 ETH บางครั้งโปรโตคอลความเป็นส่วนตัวที่ทันสมัยกว่าจะบันทึกข้อมูลที่เข้ารหัสแบบ onchain และใช้คีย์ส่วนตัวเพียงคีย์เดียวเพื่อถอดรหัส นี่เป็นความเสี่ยงเพราะหากคีย์รั่วไหลหรือหากคอมพิวเตอร์ควอนตัมทํางานได้ข้อมูลทั้งหมดจะกลายเป็นสาธารณะ การรับรอง Offchain เช่น EAS และ Zupass มีความต้องการที่ชัดเจนยิ่งขึ้นสําหรับการจัดเก็บข้อมูล offchain

กระเป๋าเงินจำเป็นต้องกลายเป็นซอฟต์แวร์ที่ไม่เพียงเพียงเก็บสิทธิ์การเข้าถึง onchain เท่านั้น แต่ยังเป็นซอฟต์แวร์ที่เก็บข้อมูลส่วนตัวของคุณด้วย นี่คือสิ่งหนึ่งที่โลก non-crypto กำลังรับรู้มากขึ้น ดูเช่น Tim Berners-Lee’s งานล่าสุดในร้านเก็บข้อมูลส่วนบุคคล. ปัญหาทั้งหมดที่เราต้องแก้ไขเกี่ยวกับการรับประกันการควบคุมสิทธิ์การเข้าถึงอย่างมีประสิทธิภาพเรายังต้องแก้ไขเกี่ยวกับการรับประกันการเข้าถึงและการไม่รั่วไหลของข้อมูล บางทีวิธีแก้ปัญหาอาจซ้อนทับกัน: หากคุณมีผู้พิทักษ์ N ให้ใช้การแบ่งปันความลับ M-of-N ระหว่างผู้พิทักษ์ N คนเดียวกันเพื่อจัดเก็บข้อมูลของคุณ ข้อมูลนั้นยากต่อการรักษาความปลอดภัยโดยเนื้อแท้เนื่องจากคุณไม่สามารถเพิกถอนส่วนแบ่งของใครบางคนได้ แต่เราควรหาโซลูชันการดูแลแบบกระจายอํานาจที่ปลอดภัยที่สุดเท่าที่จะทําได้

การเข้าถึงเชื่อมโยงที่ปลอดภัย

วันนี้ กระเป๋าเงินไว้วางใจในผู้ให้บริการ RPC เพื่อบอกข้อมูลใด ๆ เกี่ยวกับโซ่ นี่เป็นจุดเสียดสิ้นในสองทาง:

  1. ผู้ให้บริการ RPC อาจพยายามขโมยเงินโดยให้ข้อมูลที่เท็จ เช่น เกี่ยวกับราคาตลาด
  2. ผู้ให้บริการ RPC สามารถสกัดข้อมูลส่วนตัวเกี่ยวกับแอปพลิเคชันและบัญชีอื่น ๆ ที่ผู้ใช้กำลังปฏิสัมพันธ์

อย่างที่ดีที่สุดคือเราต้องการปิดภายในทั้งสองรูนี้ ในการปิดรูแรก เราต้องการไคลเอ็นต์แสงมาตราสากลสำหรับ L1 และ L2s ซึ่งตรวจสอบความเห็นของบล็อกเชนโดยตรงHelios already does this for L1, and has been doing some preliminary work to support some specific L2s. To properly cover all L2s, what we need is a standard by which a config contract representing an L2 (also used for chain-specific addresses) can declare a function, perhaps in a manner similar to ERC-3668, ซึ่งประกอบไปด้วยตัวตรวจหาราก tilไม่ทอดตรงยืนยันการส่งกลับ tilสถานะและใบเสร็จในอัตราส่วนนั้น อย่างนั้นเราสามารถมีไคลเอนต์เบาสากลที่ใช้ในการยืนยันการทำงานหรือเหตุการณ์ใด ๆ บน L1 และ L2 อย่างปลอดภัย

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

เพื่อให้เซิร์ฟเวอร์ซื่อสัตย์ รายการฐานข้อมูลแต่ละรายการเองจะเป็นสาขา Merkle ดังนั้นลูกค้าสามารถยืนยันได้โดยใช้ไคลเอ็นต์แสงของพวกเขา

PIR ต้องใช้คำนวณมากมาย มีหลายเส้นทางที่สามารถหลบหนีปัญหานี้:

  • Brute force: การปรับปรุงขั้นตอนวิธีและฮาร์ดแวร์ที่เฉพาะเจาะจงอาจทำให้ PIR ทำงานได้อย่างรวดเร็วพอที่จะใช้งานได้ ท่านทึงอาจพึงพอใจกับเทคนิคที่ขึ้นอยู่กับขั้นตอนก่อนการปฏิบัติ: เซิร์ฟเวอร์อาจจัดเก็บข้อมูลที่ถูกเข้ารหัสและสลับสลายไว้สำหรับแต่ละลูกค้าและลูกค้าสามารถสืบค้นข้อมูลดังกล่าวได้ ความท้าทายหลักในรูปแบบ Ethereum คือการปรับเปลี่ยนเทคนิคเหล่านี้ให้เข้ากันกับชุดข้อมูลที่เปลี่ยนแปลงได้อย่างรวดเร็ว (เช่นสถานะ) นี้ทำให้ค่าการคำนวณแบบทันเวลาต่ำลง แต่อาจทำให้ค่าการคำนวณทั้งหมดและค่าการจัดเก็บเพิ่มขึ้น
  • Weaken the privacy requirement: for example, each lookup could only have 1 million “mixins”, so the server would know a million possible values that the client could have accessed, but not any finer granularity
  • Multi-server PIR: อัลกอริทึม PIR มักจะเร็วกว่ามากหากคุณใช้เซิร์ฟเวอร์หลายเครื่อง โดยมีการสมมติฐานความซื่อสัตย์ 1 ใน N ระหว่างเซิร์ฟเวอร์เหล่านั้น
  • ความไม่ปรากฏตัวแทนความน่าเชื่อถือ: แทนที่จะซ่อนเนื้อหาของคำขอ คำขอสามารถถูกส่งผ่านมิกซ์เน็ตเพื่อซ่อนผู้ส่งคำขอ อย่างไรก็ตาม การทำเช่นนี้อย่างมีประสิทธิภาพอย่างไม่ได้หลีกเลี่ยงการเพิ่มความล่าช้า ทำให้ประสบการณ์ของผู้ใช้แย่ลง

การหาความสอดคล้องที่ถูกต้องของเทคนิคที่เหมาะสมในการสูงสุดของความเป็นส่วนตัวในขณะที่รักษาความเหมาะสมในบริบทของ Ethereum เป็นปัญหาการวิจัยที่เปิดเผย และฉันยินดีต้อนรับนักวิจัยที่พยายามใช้มือเขียนเข้ามาดู

กระเป๋าเงินเก็บสำคัญที่เหมาะสม

นอกเหนือจากการโอนและการเข้าถึงสถานะ กระบวนการทำงานอีกอย่างหนึ่งที่สำคัญในบริบทข้าม L2 คือการเปลี่ยนการกำหนดค่าการตรวจสอบบัญชี: ไม่ว่าจะเปลี่ยนกุญแจ (เช่นการกู้คืน) หรือการเปลี่ยนแปลงลึกลงในตรรกะทั้งหมดของบัญชี ที่นี่มีวิธีการที่สามชั้น โดยเรียงลำดับจากง่ายไปยาก

  1. อัปเดตที่เล่นซ้ำ: เมื่อผู้ใช้เปลี่ยนการกำหนดค่าของตนเอง ข้อความที่อนุญาตการเปลี่ยนแปลงนี้จะถูกเล่นซ้ำในทุกโซ่ที่กระเป๋าเงินตรวจพบว่าผู้ใช้มีสินทรัพย์ โดยอาจมีรูปแบบข้อความและกฎการตรวจสอบที่สามารถทำให้เกิดการเล่นซ้ำโดยอัตโนมัติบนโซ่มากที่สุดที่เป็นไปได้
  2. Keystores บน L1: ข้อมูลการกำหนดค่าอยู่บน L1 และกระเป๋าเงินบน L2 อ่านข้อมูลด้วยL1SLOADหรือREMOTESTATICCALL. นี่คือวิธีที่การอัปเดตการตั้งค่าจะต้องทำได้เฉพาะใน L1 เท่านั้น และการตั้งค่าจะมีผลอัตโนมัติ
  3. Keystores บน L2: ข้อมูลการกําหนดค่าอยู่บน L2 และกระเป๋าเงินบน L2 อ่านด้วย ZK-SNARK นี่เป็นเช่นเดียวกับ (2) ยกเว้นการอัปเดตคีย์สโตร์อาจมีราคาถูกกว่าแม้ว่าในทางกลับกันการอ่านจะมีราคาแพงกว่า

โซลูชัน (3) มีประสิทธิภาพเป็นพิเศษเนื่องจากเข้ากันได้ดีกับความเป็นส่วนตัว ใน "โซลูชันความเป็นส่วนตัว" ปกติผู้ใช้มีความลับ s "ค่าใบไม้" L ถูกเผยแพร่บนห่วงโซ่และผู้ใช้พิสูจน์ว่า L = hash(s, 1) และ N = hash(s, 2) สําหรับความลับบางอย่าง (ไม่เคยเปิดเผย) ที่พวกเขาควบคุม nullifier N ได้รับการเผยแพร่เพื่อให้แน่ใจว่าการใช้จ่ายในอนาคตของใบเดียวกันล้มเหลวโดยไม่เคยเปิดเผย L ขึ้นอยู่กับผู้ใช้ที่รักษาความปลอดภัย โซลูชันความเป็นส่วนตัวที่เป็นมิตรกับการกู้คืนจะพูดว่า: s คือตําแหน่ง (เช่นที่อยู่และช่องเก็บข้อมูล) onchain และผู้ใช้ต้องพิสูจน์แบบสอบถามสถานะ: L = hash(sload(sload), 1)

ความปลอดภัยของ Dapp

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

อย่างที่ควร พวกเราจะย้ายระบบนิเวศไปยังการเก็บรักษาเวอร์ชันบนเชน: ผู้ใช้จะเข้าถึงแอปพลิเคชันผ่านชื่อ ENS ของมันซึ่งจะบรรจุแฮชของ IPFS ของอินเตอร์เฟซ ธุรกรรมออนเชนจาก multisig หรือ DAO จะต้องใช้เพื่ออัพเดทอินเตอร์เฟซ วอลเล็ตจะแสดงให้ผู้ใช้เห็นว่าพวกเขากำลังโต้ตอบกับอินเตอร์เฟซออนเชนที่มีความปลอดภัยมากขึ้นหรืออินเตอร์เฟซ web2 ที่น้อยความปลอดภัย วอลเล็ตยังสามารถแสดงให้ผู้ใช้เห็นว่าพวกเขากำลังโต้ตอบกับเชนที่ปลอดภัย (เช่น ระยะ 1+ การตรวจสอบความปลอดภัยหลายรอบ)

สำหรับผู้ใช้ที่สนใจความเป็นส่วนตัว กระเป๋าเงินยังสามารถเพิ่มโหมดอย่างถ่องแท้ที่ต้องการผู้ใช้คลิกยอมรับคำขอ HTTP และไม่ใช่เพียงการดำเนินการ web3 เท่านั้น

การจำลองอินเทอร์เฟซที่เป็นไปได้สำหรับโหมดสงสัย

วิธีการที่ดีขึ้นคือการเลื่อนไปเกิน HTML + Javascript และเขียนตรรกะธุรกิจของ dapps ด้วยภาษาที่ได้รับการกำหนดเอง บางทีอาจเป็นภาษาที่เล็กน้อยและบางทีอาจเป็นจุดทับซ้อนบางอย่างเกี่ยวกับ Solidity หรือ Vyper จากนั้นเบราว์เซอร์สามารถสร้าง UI สำหรับฟังก์ชันที่จำเป็นได้โดยอัตโนมัติOKContract is doing this already.

ทิศทางอื่นคือการป้องกันข้อมูลคริปโตเอกโนมิก: นักพัฒนา dapp, บริษัทรักษาความปลอดภัย, ผู้ใช้งาน chain และผู้อื่น ๆ สามารถวางเงินปันผลที่จะได้รับการชำระเงินให้กับผู้ใช้ที่ได้รับความเสียหายหาก dapp ถูกแฮกหรือส่งผลกระทบต่อผู้ใช้โดยการกระทำอย่างที่สร้างความเข้าใจผิด ๆ โดยการตัดสินใจโดย DAO การพิจารณาบนเชือกนั้น กระเป๋าเงินสามารถแสดงคะแนนของผู้ใช้ที่อ้างอิงจากขนาดของเงินปันผลได้

อนาคตระยะยาว

ข้างต้นทั้งหมดอยู่ในบริบทของอินเทอร์เฟซทั่วไปซึ่งเกี่ยวข้องกับการชี้และคลิกที่สิ่งต่าง ๆ และป้อนสิ่งต่าง ๆ ลงในช่องข้อความ อย่างไรก็ตามเรายังอยู่ในคิวของกระบวนทัศน์ที่เปลี่ยนแปลงอย่างลึกซึ้งมากขึ้น:

  • AI ซึ่งอาจนำพาเราไปสู่จุดที่เราเคยใช้แบบกดและพิมพ์เป็นแบบพิฆาตไปสู่แบบแสดงออกว่า 'บอกว่าคุณต้องการทำอะไร แล้วบอตจะคิดออกมา'
  • อินเทอร์เฟซระหว่างสมองกับคอมพิวเตอร์ ทั้งวิธีการแบบ "ไม่รุนแรง" เช่น การติดตามดวงตา ตลอดจนเทคนิคที่ตรงและรุกรานมากขึ้น (ดู: ผู้ป่วย Neuralink คนแรกในปีนี้)
  • ลูกค้าที่มีการป้องกันแบบใช้งาน: เบรฟเบราว์เซอร์ป้องกันผู้ใช้โดยเครื่องมือต่างๆ เช่น โฆษณา ติดตาม และองค์ประกอบอื่นๆ ที่ไม่ต้องการ. หลายเบราว์เซอร์ ปลั๊กอิน และกระเป๋าเงินดิจิทัลมีทีมงานทำงานอย่างเต็มที่เพื่อปกป้องผู้ใช้จากการละเมิดความปลอดภัยและความเป็นส่วนตัวของทุกชนิด ชนิดเหล่านี้ของ "ผู้พิทักษ์ที่ให้การดูแล" จะกลายเป็นแรงขับเคลื่อนที่มีประสิทธิภาพขึ้นในทศวรรษที่กำลังจะมา

แนวโน้มทั้งสามนี้ร่วมกันจะนําไปสู่การคิดใหม่อย่างลึกซึ้งยิ่งขึ้นว่าอินเทอร์เฟซทํางานอย่างไร ด้วยการป้อนข้อมูลภาษาธรรมชาติการติดตามดวงตาหรือในที่สุด BCI โดยตรงมากขึ้นพร้อมกับความรู้เกี่ยวกับประวัติของคุณ (อาจรวมถึงข้อความตราบใดที่ข้อมูลทั้งหมดได้รับการประมวลผลในเครื่อง) "กระเป๋าเงิน" อาจได้รับแนวคิดที่ชัดเจนเกี่ยวกับสิ่งที่คุณต้องการทํา AI สามารถแปลสัญชาตญาณนั้นให้เป็น "แผนปฏิบัติการ" ที่เป็นรูปธรรม: ชุดของการโต้ตอบแบบ onchain และ offchain ที่บรรลุสิ่งที่คุณต้องการ สิ่งนี้สามารถลดความต้องการอินเทอร์เฟซผู้ใช้ของบุคคลที่สามได้อย่างมาก หากผู้ใช้โต้ตอบกับแอปพลิเคชันของบุคคลที่สาม (หรือผู้ใช้รายอื่น) AI ควรคิดอย่างเป็นปฏิปักษ์ในนามของผู้ใช้และระบุภัยคุกคามใด ๆ และแนะนําแผนปฏิบัติการเพื่อหลีกเลี่ยงภัยคุกคามเหล่านั้น ตามหลักการแล้วจะมีระบบนิเวศแบบเปิดของ AI เหล่านี้ซึ่งผลิตโดยกลุ่มต่างๆที่มีอคติและโครงสร้างแรงจูงใจที่แตกต่างกัน

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

คำปฏิเสธ:

  1. บทความนี้พิมพ์ซ้ําจาก [vitalik]. หากมีข้อโต้แย้งในการเผยแพร่นี้ กรุณาติดต่อ เกตเรียน ทีมและพวกเขาจะจัดการกับมันทันที
  2. คำโต้แย้งความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใด ๆ
  3. การแปลบทความเป็นภาษาอื่น ๆ โดยทีม Gate Learn ถูกดำเนินการ หากไม่ได้กล่าวถึง การคัดลอก การแจกจ่าย หรือการลอกเลียนแบบบทความที่แปลไว้ ถือเป็นการละเมิดกฎหมาย

สิ่งที่ฉันต้องการเห็นในกระเป๋าเงิน

กลาง12/10/2024, 4:23:35 AM
วิตาลิค บุตเตอรินพูดถึงกระเป๋าเก็บเงิน Ethereum ที่เหมาะสม โดยให้ความสำคัญกับคุณสมบัติสำคัญ เช่น การทำธุรกรรมข้าม Layer 2 การเพิ่มความปลอดภัยและการป้องกันความเป็นส่วนตัว เขาเน้นว่ากระเป๋าเงินสามารถจัดการธุรกรรม multi-chain และ cross-Layer 2 ได้อย่างราบรื่น ปรับปรุงประสบการณ์ผู้ใช้ และรองรับการเก็บรักษาข้อมูลและตัวตนแบบกระจาย นอกจากนี้ เขาย้ำความจำเป็นของการรวมฟีเจอร์ความเป็นส่วนตัว เช่น ZK-SNARKs สำหรับธุรกรรมส่วนตัว และการรักษาความปลอดภัยที่แข็งแกร่งเพื่อต่อต้านความเสี่ยงเช่นการโจมตีแฟชิง

ประสบการณ์ของผู้ใช้ในการทำธุรกรรมระหว่าง L2 ที่แตกต่างกัน

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

ไอเดียหลักคือ (i) การส่งข้าม L2 ที่ซ่อนอยู่ในตัว, และ (ii) ที่อยู่และคำขอการชำระเงินที่เฉพาะกับเครื่องหมายลายเซ็น. กระเป๋าเงินของคุณควรสามารถให้คุณที่อยู่ซึ่ง (ตามรูปแบบของ ร่างนี้ ERC) ดูเหมือนว่า

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

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

  • หากคุณมีเหรียญประเภทที่ต้องการเพียงพอในห่วงโซ่ปลายทางให้ส่งเหรียญโดยตรง
  • หากคุณมีเหรียญชนิดที่ต้องการบนโซ่อื่น ๆ (หรือหลายโซ่อื่น ๆ) ใช้โปรโตคอลเช่น gateERC-7683 (effectively a cross-chain DEX) เพื่อส่งเหรียญ
  • หากคุณมีเหรียญประเภทอื่น ๆ บนโซ่เดียวกันหรือโซ่อื่น ๆ ให้ใช้บัญชีศูนย์กลางเพื่อแปลงพวกเขาให้กลายเป็นประเภทของเหรียญที่เหมาะสมบนโซ่ที่เหมาะสมและส่งพวกเขา นี่ควรต้องการอนุญาตโดยชัดเจนจากผู้ใช้: ผู้ใช้จะเห็นว่าพวกเขาจ่ายเท่าไหร่และได้รับเท่าไหร่

ขอบเขตของอินเตอร์เฟซกระเป๋าเงินที่เป็นไปได้พร้อมการสนับสนุนที่อยู่跨ลึก

ข้างต้นเป็นสำหรับ "คุณคัดลอกและวางที่อยู่ (หรือ ENS, เช่น vitalik.eth@optimism.eth) สำหรับใครบางคนที่จะจ่ายให้คุณ" ใช้เคส หาก dapp กำลังขอฝาก (เช่น ดูตัวอย่าง Polymarket นี้) จากนั้นโฟลว์ในอุดมคติคือการขยาย web3 API และอนุญาตให้ dapp ส่งคําขอชําระเงินเฉพาะห่วงโซ่ กระเป๋าเงินของคุณจะสามารถตอบสนองคําขอนั้นได้ทุกวิถีทางที่ต้องการ การทําให้ประสบการณ์ของผู้ใช้ทํางานได้ดีจะต้องมีการกําหนดมาตรฐานคําขอ getAvailableBalance และกระเป๋าเงินจะต้องคิดให้มากว่าเครือข่ายใดที่พวกเขาจัดเก็บทรัพย์สินของผู้ใช้โดยค่าเริ่มต้นเพื่อเพิ่มความปลอดภัยและความสะดวกในการถ่ายโอน

คําขอชําระเงินเฉพาะห่วงโซ่สามารถใส่ลงในรหัส QR ซึ่งกระเป๋าเงินมือถือสามารถสแกนได้ ในสถานการณ์การชําระเงินของผู้บริโภคด้วยตนเอง (หรือออนไลน์) ผู้รับจะทํารหัส QR หรือการเรียก web3 API ที่ระบุว่า "ฉันต้องการ X หน่วยโทเค็น Y บน chain Z พร้อมรหัสอ้างอิงหรือการเรียกกลับ W" และกระเป๋าเงินจะมีอิสระที่จะตอบสนองคําขอนั้นในทุกวิถีทางที่สามารถทําได้ อีกทางเลือกหนึ่งคือโปรโตคอลลิงก์การอ้างสิทธิ์ซึ่งกระเป๋าเงินของผู้ใช้จะสร้างรหัส QR หรือ URL ที่มีการอนุญาตให้อ้างสิทธิ์เงินจํานวนหนึ่งจากสัญญา onchain ของพวกเขาและเป็นหน้าที่ของผู้รับที่จะหาวิธีย้ายเงินเหล่านั้นไปยังกระเป๋าเงินของตนเอง

หัวข้อที่เกี่ยวข้องอีกอย่างคือการชำระค่าแก๊ส หากคุณได้รับสินทรัพย์บน L2 ที่คุณยังไม่มี ETH และคุณต้องการส่งธุรกรรมบน L2 นั้น กระเป๋าสตางค์ควรสามารถใช้โปรโตคอลโดยอัตโนมัติ (เช่น RIP-7755) ในการชำระค่าแก๊สในเครือข่ายที่คุณมี ETH หากกระเป๋าเงินคาดหวังให้คุณทำธุรกรรมเพิ่มเติมบน L2 ในอนาคต ก็ควรใช้ DEX เพื่อส่งกลับเช่นเดียวกับ ETH มูลค่าก๊าซหลายล้านภายในเพื่อให้การทำธุรกรรมในอนาคตสามารถใช้ก๊าซได้โดยตรงที่นั่น (เนื่องจากมีราคาถูกกว่า)

ความปลอดภัยของบัญชี

วิธีหนึ่งที่ผมอธิบายความท้าทายด้านความปลอดภัยของบัญชีคือว่ากระเป๋าเงินที่ดีควรเป็นดีในสองด้านพร้อมกัน: (i) ป้องกันผู้ใช้ไม่ให้นักพัฒนากระเป๋าเงินถูกแฮ็กหรือทำให้เสียหาย, และ (ii) ป้องกันผู้ใช้ไม่ให้เกิดข้อผิดพลาดของตัวเอง

การพิมพ์ผิดคำว่า 'mistakles' ทางซ้ายเป็นความผิดพลาดที่ไม่ได้ตั้งใจ อย่างไรก็ตาม เมื่อเห็นมันฉันก็รู้สึกว่ามันเหมาะสมกับบริบท ดังนั้นฉันตัดสินใจเก็บไว้

วิธีที่ฉันชอบมากที่สุดสำหรับสะกดสิบปีมีการกู้คืนสังคมและกระเป๋าเงินมัลติซิกพร้อมควบคุมการเข้าถึงที่จัดเกรด บัญชีผู้ใช้มีสองชั้นของกุญแจ: กุญแจหลัก และ N ผู้พิทักษ์ (เช่น N = 5) กุญแจหลักสามารถดำเนินการที่มีค่าต่ำและไม่เกี่ยวกับการเงิน ต้องการผู้พิทักษ์ส่วนใหญ่เพื่อดำเนินการที่เป็นไปได้ทั้ง (i) ดำเนินการที่มีค่าสูง เช่น ส่งออกค่าทั้งหมดในบัญชี หรือ (ii) เปลี่ยนแปลงกุญแจหลักหรือผู้พิทักษ์ใดๆ ตามต้องการ กุญแจหลักสามารถทำการที่มีค่าสูงพร้อมกับการล็อคเวลา หากต้องการ

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

ใครหรืออะไรควรเป็นผู้คุ้มครอง?

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

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

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

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

โชคดีที่มี ZK-SNARKs เรามีทางเลือกที่สี่: ZK-wrapped centralized ID ประเภทนี้รวมถึงzk-email, Anon Aadhaar, กระเป๋าเงิน Myna, และอื่น ๆ พื้นฐานแล้วคุณสามารถใช้รูปแบบหลายรูปแบบของ ID ที่ถูก (บริษัทหรือรัฐบาล) จัดกลุ่ม และแปลงเป็นที่อยู่ Ethereum ซึ่งคุณสามารถส่งธุรกรรมได้เท่านั้นโดยการสร้างการพิสูจน์ ZK-SNARK ที่แสดงความเป็นเจ้าของของ ID ที่ถูกจัดกลุ่ม

ด้วยการเพิ่มนี้ตอนนี้เรามีตัวเลือกมากมายและ ID ส่วนกลางที่ห่อหุ้มด้วย ZK นั้น "เป็นมิตรกับ noob" โดยเฉพาะ

สำหรับการทำงานนี้ จะต้องนำมาใช้ร่วมกับ UI ที่ได้รับการรวมรวมและรวมร่างไว้: คุณควรสามารถระบุได้เพียงแค่ว่าคุณต้องการexample@gmail.comเป็นผู้ปกครอง และควรสร้างที่อยู่อีเธอเรียม zk-email ที่เกี่ยวข้องโดยอัตโนมัติภายใน ผู้ใช้ขั้นสูงควรสามารถป้อนอีเมลของพวกเขา (พร้อมกับค่าเกลือสำหรับความเป็นส่วนตัวบางอย่าง ซึ่งจะถูกบันทึกไว้ในอีเมลนั้น) เข้าสู่แอปพลิเคชั่นบุคคลสามที่เปิดออกและยืนยันว่าที่อยู่ที่สร้างขึ้นถูกต้อง สิ่งเดียวกันควรเป็นจริงสำหรับประเภทผู้ปกครองที่รองรับอื่น ๆ ทุกประการ

โมคัพของอินเตอร์เฟซที่เป็นไปได้

โปรดทราบว่าวันนี้ความท้าทายในทางปฏิบัติอย่างหนึ่งของ zk-email โดยเฉพาะคือมันขึ้นอยู่กับ ลายเซ็น DKIMซึ่งใช้คีย์ที่หมุนทุกๆ สองสามเดือน และคีย์เหล่านี้ไม่ได้ลงนามโดยหน่วยงานอื่นใด ซึ่งหมายความว่า zk-email ในปัจจุบันมีข้อกําหนดด้านความไว้วางใจในระดับหนึ่งนอกเหนือจากผู้ให้บริการเอง สิ่งนี้อาจลดลงได้หากใช้ ZK-email TLSNotaryสำหรับการยืนยันคีย์ DKIM ผมหวังว่าผู้ให้บริการอีเมลจะเริ่มเซ็นต์คีย์ DKIM ของพวกเขาโดยตรง วันนี้ผมขอแนะนำให้ใช้ zk-email สำหรับ Guardian คนเดียว แต่ไม่ใช่สำหรับ Guardian ส่วนใหญ่: อย่าเก็บเงินในระบบที่ zk-email ขัดข้องหมายถึงคุณสูญเสียการเข้าถึงเงินของคุณ

ผู้ใช้ใหม่และกระเป๋าเงินในแอป

ผู้ใช้ใหม่ในความเป็นจริงจะไม่ต้องการที่จะต้องป้อนจำนวนผู้ปกครองมากในประสบการณ์การสมัครครั้งแรกของพวกเขา ดังนั้นกระเป๋าเงินควรมีตัวเลือกที่ง่ายมากสำหรับพวกเขา หนึ่งเส้นทางธรรมชาติคือ 2-of-3 โดยใช้ zk-email บนที่อยู่อีเมลของพวกเขา คีย์ที่เก็บไว้ในอุปกรณ์ของผู้ใช้ (ซึ่งอาจเป็นรหัสผ่าน) และคีย์สำรองที่ถือโดยผู้ให้บริการ ในขณะที่ผู้ใช้เริ่มเชี่ยวชาญมากขึ้นหรือสะสมสินทรัพย์มากขึ้น ในบางจุดพวกเขาควรได้รับการเรียกให้เพิ่มผู้ปกครองเพิ่มเติม

กระเป๋าเงินที่รวมอยู่ในแอปพลิเคชันเป็นสิ่งที่หลีกเลี่ยงไม่ได้เนื่องจากแอปพลิเคชันที่พยายามดึงดูดผู้ใช้ที่ไม่ใช่ crypto ไม่ต้องการประสบการณ์การใช้งานที่สับสนในการขอให้ผู้ใช้ดาวน์โหลดแอปพลิเคชันใหม่สองรายการ (ตัวแอปเองรวมถึงกระเป๋าเงิน Ethereum) ในเวลาเดียวกัน อย่างไรก็ตามผู้ใช้กระเป๋าเงินแอปพลิเคชันจํานวนมากควรสามารถเชื่อมโยงกระเป๋าเงินทั้งหมดเข้าด้วยกันเพื่อให้พวกเขามี "สิ่งที่ควบคุมการเข้าถึง" เพียงสิ่งเดียวที่ต้องกังวล วิธีที่ง่ายที่สุดในการทําเช่นนี้คือรูปแบบลําดับชั้นซึ่งมีกระบวนการ "เชื่อมโยง" ที่รวดเร็วซึ่งช่วยให้ผู้ใช้สามารถตั้งค่ากระเป๋าเงินหลักให้เป็นผู้พิทักษ์กระเป๋าเงินในแอปทั้งหมดได้ ไคลเอนต์ Farcaster Warpcast รองรับสิ่งนี้แล้ว:

โดยค่าเริ่มต้นการกู้คืนบัญชี Warpcast ของคุณถูกควบคุมโดยทีม Warpcast อย่างไรก็ตามคุณสามารถ “เอาถิ่นสำหรับ” บัญชี Farcaster ของคุณ และเปลี่ยนการกู้คืนไปยังที่อยู่ของคุณเอง

การป้องกันผู้ใช้จากการโกงและอุปสรรคจากภายนอกอื่น ๆ

นอกจากความปลอดภัยของบัญชีแล้ว กระเป๋าเงินวันนี้ทำมากเพื่อระบุที่อยู่ปลอม การจ phishing โกหก และอุปกรณ์คุกคามอื่น ๆ และพยายามปกป้องผู้ใช้ของพวกเขาจากอันตรายเช่นนี้ ในเวลาเดียวกัน มีหลายวิธีที่ใช้สำหรับการต้านต่อยังคงค่อนข้างโดยรวม: เช่น การกำหนดค่าการคลิกเพื่อส่ง ETH หรือโทเคนใด ๆ ไปยังที่อยู่ใหม่ ๆ โดยไม่ว่าคุณจะส่ง $100 หรือ $100,000 ที่นี่ไม่มีทางแก้ไขแบบเดียวกัน; มันเป็นชุดของการแก้ไขที่รวดเร็วและการปรับปรุงต่อเนื่องในหมวดหมู่ต่าง ๆ ของอันตราย อย่างไรก็ตาม มีค่ามากในการทำงานหนักเพื่อปรับปรุงที่นี่

ความเป็นส่วนตัว

ตอนนี้เวลาที่จะเริ่มให้ความสำคัญกับความเป็นส่วนตัวบน Ethereum มากขึ้น เทคโนโลยี ZK-SNARK ได้ก้าวหน้ามาก เทคโนโลยีความเป็นส่วนตัวที่ช่วยลดความเสี่ยงทางกฎหมายโดยไม่ต้องพึ่งพาทางหลัง เช่น Privacy Poolsกำลังเติบโตและเจริญเติบโตมากขึ้นเรื่อย ๆ และพื้นฐานทางด้านระบบย่อยเช่น Wakuและ mempools ERC-4337 กำลังเริ่มทำให้เสถียรมากขึ้น อย่างไรก็ตาม จนถึงตอนนี้ การทำธุรกรรมเงินส่วนตัวบน Ethereum ต้องการผู้ใช้งานจะต้องดาวน์โหลดและใช้ "กระเป๋าเงินความเป็นส่วนตัว" เช่นรถไฟ (or Umbraสำหรับstealth addresses). นี้ทำให้มีความไม่สะดวกสำหรับผู้ที่ต้องการทำการโอนเงินส่วนตัวและลดจำนวนคนที่เต็มใจที่จะทำการโอนเงินส่วนตัว วิธีการแก้ไขคือการรวมการโอนเงินส่วนตัวเข้ากับกระเป๋าเงินโดยตรง

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

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

หนึ่งในข้อดีของเทคนิคนี้คือเป็นทางเลือกธรรมชาติที่สามารถทำให้การโอนทรัพย์สินที่คุ้มครองความเป็นส่วนตัวและบุคคลภาพที่คุ้มครองความเป็นส่วนตัวเกิดขึ้นได้ สิ่งที่เกิดขึ้นบนเชือกอยู่แล้ว: แอปพลิเคชันใด ๆ ที่ใช้การจัดการเป็นหลักฐานเพื่อความเป็นตัวตน (เช่น Gitcoin Grants) การสนทนาผ่านเชือกของโทเคน และ Ethereum ปฏิบัติตามโปรโตคอลและอื่น ๆ อีกมากมายล้วนเป็นอัตลักษณ์ของ onchain เราต้องการให้ระบบนิเวศนี้รักษาความเป็นส่วนตัวด้วย ซึ่งหมายความว่าไม่ควรรวบรวมกิจกรรมของผู้ใช้ในที่เดียว: แต่ละรายการควรจัดเก็บแยกต่างหากและกระเป๋าเงินของผู้ใช้ควรเป็นสิ่งเดียวที่มี "มุมมองส่วนกลาง" ที่เห็นการรับรองทั้งหมดของคุณในเวลาเดียวกัน ระบบนิเวศแบบหลายบัญชีต่อผู้ใช้ช่วยให้บรรลุเป้าหมายนี้เช่นเดียวกับโปรโตคอลการรับรอง offchain เช่น EASและZupass.

สิ่งนี้แสดงถึงวิสัยทัศน์ในทางปฏิบัติสําหรับความเป็นส่วนตัวของ Ethereum ในอนาคตระยะกลาง สามารถใช้งานได้ในปัจจุบันแม้ว่าจะมีคุณสมบัติที่สามารถแนะนําได้ที่ L1 และ L2 เพื่อให้การถ่ายโอนที่รักษาความเป็นส่วนตัวมีประสิทธิภาพและเชื่อถือได้มากขึ้น ผู้สนับสนุนความเป็นส่วนตัวบางคนยืนยันว่าสิ่งเดียวที่ยอมรับได้คือความเป็นส่วนตัวทั้งหมดของทุกสิ่ง: การเข้ารหัส EVM ทั้งหมด ฉันจะยืนยันว่านี่อาจเหมาะเป็นผลลัพธ์ระยะยาว แต่ต้องมีการทบทวนรูปแบบการเขียนโปรแกรมขั้นพื้นฐานมากขึ้นและขณะนี้ยังไม่ถึงระดับวุฒิภาวะที่พร้อมจะไปและปรับใช้ทั่วทั้ง Ethereum เราต้องการความเป็นส่วนตัวโดยค่าเริ่มต้นเพื่อให้ได้ชุดการไม่เปิดเผยตัวตนที่มีขนาดใหญ่เพียงพอ อย่างไรก็ตามการมุ่งเน้นไปที่ (i) การโอนระหว่างบัญชีและ (ii) กรณีการใช้งานข้อมูลประจําตัวและข้อมูลประจําตัวที่อยู่ติดกันเช่นการรับรองส่วนตัวเป็นขั้นตอนแรกในทางปฏิบัติที่ง่ายต่อการนําไปใช้และกระเป๋าเงินใดที่สามารถเริ่มต้นได้ในวันนี้

กระเป๋าเงิน Ethereum ต้องกลายเป็นกระเป๋าข้อมูลด้วย

ผลที่ตามมาอย่างหนึ่งของโซลูชันความเป็นส่วนตัวที่มีประสิทธิภาพไม่ว่าจะเป็นการชําระเงินหรือข้อมูลประจําตัวหรือกรณีการใช้งานอื่น ๆ คือมันสร้างความต้องการสําหรับผู้ใช้ในการจัดเก็บข้อมูล offchain สิ่งนี้ชัดเจนใน Tornado Cash ซึ่งกําหนดให้ผู้ใช้บันทึก "โน้ต" แต่ละรายการซึ่งแสดงถึงเงินฝาก 0.1-100 ETH บางครั้งโปรโตคอลความเป็นส่วนตัวที่ทันสมัยกว่าจะบันทึกข้อมูลที่เข้ารหัสแบบ onchain และใช้คีย์ส่วนตัวเพียงคีย์เดียวเพื่อถอดรหัส นี่เป็นความเสี่ยงเพราะหากคีย์รั่วไหลหรือหากคอมพิวเตอร์ควอนตัมทํางานได้ข้อมูลทั้งหมดจะกลายเป็นสาธารณะ การรับรอง Offchain เช่น EAS และ Zupass มีความต้องการที่ชัดเจนยิ่งขึ้นสําหรับการจัดเก็บข้อมูล offchain

กระเป๋าเงินจำเป็นต้องกลายเป็นซอฟต์แวร์ที่ไม่เพียงเพียงเก็บสิทธิ์การเข้าถึง onchain เท่านั้น แต่ยังเป็นซอฟต์แวร์ที่เก็บข้อมูลส่วนตัวของคุณด้วย นี่คือสิ่งหนึ่งที่โลก non-crypto กำลังรับรู้มากขึ้น ดูเช่น Tim Berners-Lee’s งานล่าสุดในร้านเก็บข้อมูลส่วนบุคคล. ปัญหาทั้งหมดที่เราต้องแก้ไขเกี่ยวกับการรับประกันการควบคุมสิทธิ์การเข้าถึงอย่างมีประสิทธิภาพเรายังต้องแก้ไขเกี่ยวกับการรับประกันการเข้าถึงและการไม่รั่วไหลของข้อมูล บางทีวิธีแก้ปัญหาอาจซ้อนทับกัน: หากคุณมีผู้พิทักษ์ N ให้ใช้การแบ่งปันความลับ M-of-N ระหว่างผู้พิทักษ์ N คนเดียวกันเพื่อจัดเก็บข้อมูลของคุณ ข้อมูลนั้นยากต่อการรักษาความปลอดภัยโดยเนื้อแท้เนื่องจากคุณไม่สามารถเพิกถอนส่วนแบ่งของใครบางคนได้ แต่เราควรหาโซลูชันการดูแลแบบกระจายอํานาจที่ปลอดภัยที่สุดเท่าที่จะทําได้

การเข้าถึงเชื่อมโยงที่ปลอดภัย

วันนี้ กระเป๋าเงินไว้วางใจในผู้ให้บริการ RPC เพื่อบอกข้อมูลใด ๆ เกี่ยวกับโซ่ นี่เป็นจุดเสียดสิ้นในสองทาง:

  1. ผู้ให้บริการ RPC อาจพยายามขโมยเงินโดยให้ข้อมูลที่เท็จ เช่น เกี่ยวกับราคาตลาด
  2. ผู้ให้บริการ RPC สามารถสกัดข้อมูลส่วนตัวเกี่ยวกับแอปพลิเคชันและบัญชีอื่น ๆ ที่ผู้ใช้กำลังปฏิสัมพันธ์

อย่างที่ดีที่สุดคือเราต้องการปิดภายในทั้งสองรูนี้ ในการปิดรูแรก เราต้องการไคลเอ็นต์แสงมาตราสากลสำหรับ L1 และ L2s ซึ่งตรวจสอบความเห็นของบล็อกเชนโดยตรงHelios already does this for L1, and has been doing some preliminary work to support some specific L2s. To properly cover all L2s, what we need is a standard by which a config contract representing an L2 (also used for chain-specific addresses) can declare a function, perhaps in a manner similar to ERC-3668, ซึ่งประกอบไปด้วยตัวตรวจหาราก tilไม่ทอดตรงยืนยันการส่งกลับ tilสถานะและใบเสร็จในอัตราส่วนนั้น อย่างนั้นเราสามารถมีไคลเอนต์เบาสากลที่ใช้ในการยืนยันการทำงานหรือเหตุการณ์ใด ๆ บน L1 และ L2 อย่างปลอดภัย

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

เพื่อให้เซิร์ฟเวอร์ซื่อสัตย์ รายการฐานข้อมูลแต่ละรายการเองจะเป็นสาขา Merkle ดังนั้นลูกค้าสามารถยืนยันได้โดยใช้ไคลเอ็นต์แสงของพวกเขา

PIR ต้องใช้คำนวณมากมาย มีหลายเส้นทางที่สามารถหลบหนีปัญหานี้:

  • Brute force: การปรับปรุงขั้นตอนวิธีและฮาร์ดแวร์ที่เฉพาะเจาะจงอาจทำให้ PIR ทำงานได้อย่างรวดเร็วพอที่จะใช้งานได้ ท่านทึงอาจพึงพอใจกับเทคนิคที่ขึ้นอยู่กับขั้นตอนก่อนการปฏิบัติ: เซิร์ฟเวอร์อาจจัดเก็บข้อมูลที่ถูกเข้ารหัสและสลับสลายไว้สำหรับแต่ละลูกค้าและลูกค้าสามารถสืบค้นข้อมูลดังกล่าวได้ ความท้าทายหลักในรูปแบบ Ethereum คือการปรับเปลี่ยนเทคนิคเหล่านี้ให้เข้ากันกับชุดข้อมูลที่เปลี่ยนแปลงได้อย่างรวดเร็ว (เช่นสถานะ) นี้ทำให้ค่าการคำนวณแบบทันเวลาต่ำลง แต่อาจทำให้ค่าการคำนวณทั้งหมดและค่าการจัดเก็บเพิ่มขึ้น
  • Weaken the privacy requirement: for example, each lookup could only have 1 million “mixins”, so the server would know a million possible values that the client could have accessed, but not any finer granularity
  • Multi-server PIR: อัลกอริทึม PIR มักจะเร็วกว่ามากหากคุณใช้เซิร์ฟเวอร์หลายเครื่อง โดยมีการสมมติฐานความซื่อสัตย์ 1 ใน N ระหว่างเซิร์ฟเวอร์เหล่านั้น
  • ความไม่ปรากฏตัวแทนความน่าเชื่อถือ: แทนที่จะซ่อนเนื้อหาของคำขอ คำขอสามารถถูกส่งผ่านมิกซ์เน็ตเพื่อซ่อนผู้ส่งคำขอ อย่างไรก็ตาม การทำเช่นนี้อย่างมีประสิทธิภาพอย่างไม่ได้หลีกเลี่ยงการเพิ่มความล่าช้า ทำให้ประสบการณ์ของผู้ใช้แย่ลง

การหาความสอดคล้องที่ถูกต้องของเทคนิคที่เหมาะสมในการสูงสุดของความเป็นส่วนตัวในขณะที่รักษาความเหมาะสมในบริบทของ Ethereum เป็นปัญหาการวิจัยที่เปิดเผย และฉันยินดีต้อนรับนักวิจัยที่พยายามใช้มือเขียนเข้ามาดู

กระเป๋าเงินเก็บสำคัญที่เหมาะสม

นอกเหนือจากการโอนและการเข้าถึงสถานะ กระบวนการทำงานอีกอย่างหนึ่งที่สำคัญในบริบทข้าม L2 คือการเปลี่ยนการกำหนดค่าการตรวจสอบบัญชี: ไม่ว่าจะเปลี่ยนกุญแจ (เช่นการกู้คืน) หรือการเปลี่ยนแปลงลึกลงในตรรกะทั้งหมดของบัญชี ที่นี่มีวิธีการที่สามชั้น โดยเรียงลำดับจากง่ายไปยาก

  1. อัปเดตที่เล่นซ้ำ: เมื่อผู้ใช้เปลี่ยนการกำหนดค่าของตนเอง ข้อความที่อนุญาตการเปลี่ยนแปลงนี้จะถูกเล่นซ้ำในทุกโซ่ที่กระเป๋าเงินตรวจพบว่าผู้ใช้มีสินทรัพย์ โดยอาจมีรูปแบบข้อความและกฎการตรวจสอบที่สามารถทำให้เกิดการเล่นซ้ำโดยอัตโนมัติบนโซ่มากที่สุดที่เป็นไปได้
  2. Keystores บน L1: ข้อมูลการกำหนดค่าอยู่บน L1 และกระเป๋าเงินบน L2 อ่านข้อมูลด้วยL1SLOADหรือREMOTESTATICCALL. นี่คือวิธีที่การอัปเดตการตั้งค่าจะต้องทำได้เฉพาะใน L1 เท่านั้น และการตั้งค่าจะมีผลอัตโนมัติ
  3. Keystores บน L2: ข้อมูลการกําหนดค่าอยู่บน L2 และกระเป๋าเงินบน L2 อ่านด้วย ZK-SNARK นี่เป็นเช่นเดียวกับ (2) ยกเว้นการอัปเดตคีย์สโตร์อาจมีราคาถูกกว่าแม้ว่าในทางกลับกันการอ่านจะมีราคาแพงกว่า

โซลูชัน (3) มีประสิทธิภาพเป็นพิเศษเนื่องจากเข้ากันได้ดีกับความเป็นส่วนตัว ใน "โซลูชันความเป็นส่วนตัว" ปกติผู้ใช้มีความลับ s "ค่าใบไม้" L ถูกเผยแพร่บนห่วงโซ่และผู้ใช้พิสูจน์ว่า L = hash(s, 1) และ N = hash(s, 2) สําหรับความลับบางอย่าง (ไม่เคยเปิดเผย) ที่พวกเขาควบคุม nullifier N ได้รับการเผยแพร่เพื่อให้แน่ใจว่าการใช้จ่ายในอนาคตของใบเดียวกันล้มเหลวโดยไม่เคยเปิดเผย L ขึ้นอยู่กับผู้ใช้ที่รักษาความปลอดภัย โซลูชันความเป็นส่วนตัวที่เป็นมิตรกับการกู้คืนจะพูดว่า: s คือตําแหน่ง (เช่นที่อยู่และช่องเก็บข้อมูล) onchain และผู้ใช้ต้องพิสูจน์แบบสอบถามสถานะ: L = hash(sload(sload), 1)

ความปลอดภัยของ Dapp

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

อย่างที่ควร พวกเราจะย้ายระบบนิเวศไปยังการเก็บรักษาเวอร์ชันบนเชน: ผู้ใช้จะเข้าถึงแอปพลิเคชันผ่านชื่อ ENS ของมันซึ่งจะบรรจุแฮชของ IPFS ของอินเตอร์เฟซ ธุรกรรมออนเชนจาก multisig หรือ DAO จะต้องใช้เพื่ออัพเดทอินเตอร์เฟซ วอลเล็ตจะแสดงให้ผู้ใช้เห็นว่าพวกเขากำลังโต้ตอบกับอินเตอร์เฟซออนเชนที่มีความปลอดภัยมากขึ้นหรืออินเตอร์เฟซ web2 ที่น้อยความปลอดภัย วอลเล็ตยังสามารถแสดงให้ผู้ใช้เห็นว่าพวกเขากำลังโต้ตอบกับเชนที่ปลอดภัย (เช่น ระยะ 1+ การตรวจสอบความปลอดภัยหลายรอบ)

สำหรับผู้ใช้ที่สนใจความเป็นส่วนตัว กระเป๋าเงินยังสามารถเพิ่มโหมดอย่างถ่องแท้ที่ต้องการผู้ใช้คลิกยอมรับคำขอ HTTP และไม่ใช่เพียงการดำเนินการ web3 เท่านั้น

การจำลองอินเทอร์เฟซที่เป็นไปได้สำหรับโหมดสงสัย

วิธีการที่ดีขึ้นคือการเลื่อนไปเกิน HTML + Javascript และเขียนตรรกะธุรกิจของ dapps ด้วยภาษาที่ได้รับการกำหนดเอง บางทีอาจเป็นภาษาที่เล็กน้อยและบางทีอาจเป็นจุดทับซ้อนบางอย่างเกี่ยวกับ Solidity หรือ Vyper จากนั้นเบราว์เซอร์สามารถสร้าง UI สำหรับฟังก์ชันที่จำเป็นได้โดยอัตโนมัติOKContract is doing this already.

ทิศทางอื่นคือการป้องกันข้อมูลคริปโตเอกโนมิก: นักพัฒนา dapp, บริษัทรักษาความปลอดภัย, ผู้ใช้งาน chain และผู้อื่น ๆ สามารถวางเงินปันผลที่จะได้รับการชำระเงินให้กับผู้ใช้ที่ได้รับความเสียหายหาก dapp ถูกแฮกหรือส่งผลกระทบต่อผู้ใช้โดยการกระทำอย่างที่สร้างความเข้าใจผิด ๆ โดยการตัดสินใจโดย DAO การพิจารณาบนเชือกนั้น กระเป๋าเงินสามารถแสดงคะแนนของผู้ใช้ที่อ้างอิงจากขนาดของเงินปันผลได้

อนาคตระยะยาว

ข้างต้นทั้งหมดอยู่ในบริบทของอินเทอร์เฟซทั่วไปซึ่งเกี่ยวข้องกับการชี้และคลิกที่สิ่งต่าง ๆ และป้อนสิ่งต่าง ๆ ลงในช่องข้อความ อย่างไรก็ตามเรายังอยู่ในคิวของกระบวนทัศน์ที่เปลี่ยนแปลงอย่างลึกซึ้งมากขึ้น:

  • AI ซึ่งอาจนำพาเราไปสู่จุดที่เราเคยใช้แบบกดและพิมพ์เป็นแบบพิฆาตไปสู่แบบแสดงออกว่า 'บอกว่าคุณต้องการทำอะไร แล้วบอตจะคิดออกมา'
  • อินเทอร์เฟซระหว่างสมองกับคอมพิวเตอร์ ทั้งวิธีการแบบ "ไม่รุนแรง" เช่น การติดตามดวงตา ตลอดจนเทคนิคที่ตรงและรุกรานมากขึ้น (ดู: ผู้ป่วย Neuralink คนแรกในปีนี้)
  • ลูกค้าที่มีการป้องกันแบบใช้งาน: เบรฟเบราว์เซอร์ป้องกันผู้ใช้โดยเครื่องมือต่างๆ เช่น โฆษณา ติดตาม และองค์ประกอบอื่นๆ ที่ไม่ต้องการ. หลายเบราว์เซอร์ ปลั๊กอิน และกระเป๋าเงินดิจิทัลมีทีมงานทำงานอย่างเต็มที่เพื่อปกป้องผู้ใช้จากการละเมิดความปลอดภัยและความเป็นส่วนตัวของทุกชนิด ชนิดเหล่านี้ของ "ผู้พิทักษ์ที่ให้การดูแล" จะกลายเป็นแรงขับเคลื่อนที่มีประสิทธิภาพขึ้นในทศวรรษที่กำลังจะมา

แนวโน้มทั้งสามนี้ร่วมกันจะนําไปสู่การคิดใหม่อย่างลึกซึ้งยิ่งขึ้นว่าอินเทอร์เฟซทํางานอย่างไร ด้วยการป้อนข้อมูลภาษาธรรมชาติการติดตามดวงตาหรือในที่สุด BCI โดยตรงมากขึ้นพร้อมกับความรู้เกี่ยวกับประวัติของคุณ (อาจรวมถึงข้อความตราบใดที่ข้อมูลทั้งหมดได้รับการประมวลผลในเครื่อง) "กระเป๋าเงิน" อาจได้รับแนวคิดที่ชัดเจนเกี่ยวกับสิ่งที่คุณต้องการทํา AI สามารถแปลสัญชาตญาณนั้นให้เป็น "แผนปฏิบัติการ" ที่เป็นรูปธรรม: ชุดของการโต้ตอบแบบ onchain และ offchain ที่บรรลุสิ่งที่คุณต้องการ สิ่งนี้สามารถลดความต้องการอินเทอร์เฟซผู้ใช้ของบุคคลที่สามได้อย่างมาก หากผู้ใช้โต้ตอบกับแอปพลิเคชันของบุคคลที่สาม (หรือผู้ใช้รายอื่น) AI ควรคิดอย่างเป็นปฏิปักษ์ในนามของผู้ใช้และระบุภัยคุกคามใด ๆ และแนะนําแผนปฏิบัติการเพื่อหลีกเลี่ยงภัยคุกคามเหล่านั้น ตามหลักการแล้วจะมีระบบนิเวศแบบเปิดของ AI เหล่านี้ซึ่งผลิตโดยกลุ่มต่างๆที่มีอคติและโครงสร้างแรงจูงใจที่แตกต่างกัน

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

คำปฏิเสธ:

  1. บทความนี้พิมพ์ซ้ําจาก [vitalik]. หากมีข้อโต้แย้งในการเผยแพร่นี้ กรุณาติดต่อ เกตเรียน ทีมและพวกเขาจะจัดการกับมันทันที
  2. คำโต้แย้งความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใด ๆ
  3. การแปลบทความเป็นภาษาอื่น ๆ โดยทีม Gate Learn ถูกดำเนินการ หากไม่ได้กล่าวถึง การคัดลอก การแจกจ่าย หรือการลอกเลียนแบบบทความที่แปลไว้ ถือเป็นการละเมิดกฎหมาย
เริ่มตอนนี้
สมัครและรับรางวัล
$100