Vitalik: การเปลี่ยนแปลงที่จำเป็นของ Ethereum - การปรับขนาด L2 ความปลอดภัยของกระเป๋าเงินและความเป็นส่วนตัว

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

การปรับมาตราส่วน L2 - ย้ายข้อมูลทั้งหมดไปยังการยกเลิก

Wallet Security Shift - โอนย้ายทั้งหมดไปยัง Smart Contract Wallet

การเปลี่ยนแปลงความเป็นส่วนตัว - ตรวจสอบให้แน่ใจว่าการโอนเงินที่รักษาความเป็นส่วนตัวและให้แน่ใจว่าเครื่องมืออื่น ๆ ทั้งหมดที่กำลังพัฒนา (การกู้คืนทางสังคม, ตัวตน, ชื่อเสียง) นั้นรักษาความเป็นส่วนตัว

นี่คือรูปสามเหลี่ยมของการเปลี่ยนแปลงระบบนิเวศ คุณสามารถเลือกได้เพียง 3 ใน 3 เท่านั้น

หากไม่มีอันแรก Ethereum จะล้มเหลวเพราะแต่ละธุรกรรมจะมีราคา $3.75 ($82.48 หากเราเข้าสู่ภาวะกระทิงอีกครั้ง) และในที่สุดผลิตภัณฑ์ในตลาดมวลชนทั้งหมดก็จะลืมห่วงโซ่และใช้โซลูชันแบบรวมศูนย์สำหรับทุกสิ่ง

หากไม่มีอย่างที่สอง Ethereum จะล้มเหลวเนื่องจากผู้ใช้จะไม่เต็มใจที่จะเก็บเงิน (และสินทรัพย์ที่ไม่ใช่ทางการเงิน) และทั้งหมดจะย้ายไปที่การแลกเปลี่ยนแบบรวมศูนย์

หากไม่มีหนึ่งในสาม Ethereum จะล้มเหลว เนื่องจากธุรกรรมทั้งหมด (และ POAP เป็นต้น) จะเปิดเผยต่อสาธารณะสำหรับใครก็ตามที่มองเห็น ซึ่งจะเป็นการเสียสละความเป็นส่วนตัวมากเกินไปสำหรับผู้ใช้จำนวนมาก และทุกคนจะย้ายไปยังศูนย์ข้อมูลที่ซ่อนอยู่อย่างน้อยบางส่วน สารละลาย.

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

การเปลี่ยนแปลงทั้งสามนี้จะปฏิวัติความสัมพันธ์ระหว่างผู้ใช้และที่อยู่

ในโลกที่ขยาย L2 ผู้ใช้จะมีอยู่ใน L2 จำนวนมาก คุณเป็นสมาชิกของ ExampleDAO ซึ่งอยู่บนการมองโลกในแง่ดีหรือไม่? ถ้าอย่างนั้นคุณมีบัญชีในการมองโลกในแง่ดี! คุณถือ CDP ในระบบ Stablecoin ของ ZkSync หรือไม่? จากนั้นคุณมีบัญชีบน ZkSync! คุณเคยลองแอพบางตัวที่อยู่ใน Kakarot หรือไม่? ถ้าอย่างนั้นคุณมีบัญชีใน Kakarot! หมดยุคที่ผู้ใช้มีที่อยู่เดียว

ฉันมี ETH อยู่สี่แห่ง ตามมุมมองของ Brave Wallet ของฉัน ใช่ Arbitrum และ Arbitrum Nova นั้นแตกต่างกัน ไม่ต้องกังวล สิ่งนี้จะซับซ้อนมากขึ้นเมื่อเวลาผ่านไป!

กระเป๋าเงินสัญญาอัจฉริยะเพิ่มความซับซ้อนมากขึ้น ทำให้ยากขึ้นที่จะมีที่อยู่เดียวกันใน L1 และ L2 ต่างๆ ทุกวันนี้ ผู้ใช้ส่วนใหญ่กำลังใช้บัญชีที่บุคคลภายนอกเป็นเจ้าของ ซึ่งจริงๆ แล้วที่อยู่เป็นแฮชของคีย์สาธารณะที่ใช้ในการตรวจสอบลายเซ็น ดังนั้นจึงไม่มีอะไรเปลี่ยนแปลงระหว่าง L1 และ L2 อย่างไรก็ตาม ด้วยกระเป๋าเงินสัญญาอัจฉริยะ การรักษาที่อยู่กลายเป็นเรื่องยากขึ้น ในขณะที่มีงานจำนวนมากที่พยายามสร้างที่อยู่แฮชของโค้ดที่เทียบเท่ากันทั่วทั้งเครือข่าย โดยเฉพาะอย่างยิ่งโรงงาน CREATE2 และ ERC-2470 แบบซิงเกิลตัน เป็นเรื่องยากมากที่จะทำสิ่งนี้ให้สมบูรณ์แบบ L2 บางตัว (เช่น "ประเภท 4 ZK-EVM") ไม่เทียบเท่ากับ EVM อย่างสมบูรณ์ โดยปกติจะใช้ Solidity หรือชุดประกอบระดับกลางแทน ป้องกันการเทียบเท่าแฮช แม้ว่าคุณจะมีความเท่าเทียมกันของแฮช แต่ความเป็นไปได้ที่กระเป๋าเงินจะเปลี่ยนความเป็นเจ้าของผ่านการเปลี่ยนแปลงคีย์นั้นมีผลตามมาที่ไม่ได้เกิดขึ้นเอง

ความเป็นส่วนตัวต้องการที่อยู่ต่อผู้ใช้มากขึ้น และอาจเปลี่ยนประเภทที่อยู่ที่เราจัดการด้วย หากใช้ข้อเสนอที่อยู่ส่วนตัวกันอย่างแพร่หลาย แทนที่จะใช้เพียงไม่กี่ที่อยู่ต่อผู้ใช้หรือหนึ่งที่อยู่ต่อ L2 อาจมีหนึ่งที่อยู่ต่อธุรกรรม รูปแบบความเป็นส่วนตัวอื่น ๆ แม้กระทั่งที่มีอยู่เช่น Tornado Cash เปลี่ยนวิธีการจัดเก็บสินทรัพย์ให้แตกต่างออกไป: เงินของผู้ใช้จำนวนมากจะถูกเก็บไว้ในสัญญาอัจฉริยะเดียวกัน (และดังนั้นในที่อยู่เดียวกัน) ในการส่งเงินไปยังผู้ใช้เฉพาะ ผู้ใช้จำเป็นต้องอาศัยระบบที่อยู่ภายในของแผนความเป็นส่วนตัว

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

1. หากคุณต้องการจ่ายเงินให้ใครสักคน คุณจะได้รับข้อมูลเพื่อจ่ายเงินให้พวกเขาได้อย่างไร?

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

การเปลี่ยนสามครั้งเกี่ยวข้องกับการชำระเงินออนไลน์ (และตัวตน)

ฉันมีเหรียญบน Scroll และฉันต้องการจ่ายค่ากาแฟ (หาก "ฉัน" หมายถึงฉันในฐานะผู้เขียนบทความนี้ตามตัวอักษร แน่นอนว่า "กาแฟ" เป็นคำพ้องความหมายสำหรับ "ชาเขียว") คุณกำลังขายกาแฟให้ฉัน แต่คุณจะได้รับเฉพาะเหรียญใน Taiko ฉันจะทำอย่างไร

โดยทั่วไปมีสองวิธีแก้ไข:

1. กระเป๋าเงินรับ (อาจเป็นผู้ค้าหรือแค่บุคคลทั่วไป) มุ่งมั่นที่จะสนับสนุนแต่ละ L2 ด้วยฟังก์ชันอัตโนมัติบางอย่างเพื่อรวมเงินแบบอะซิงโครนัส

2. ผู้รับระบุ L2 และที่อยู่ของพวกเขา และกระเป๋าเงินของผู้ส่งจะกำหนดเส้นทางเงินไปยัง L2 เป้าหมายโดยอัตโนมัติผ่านระบบเชื่อมโยงระหว่าง L2 บางประเภท

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

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

โชคดีที่การเปลี่ยนมาใช้กระเป๋าเงินสัญญาอัจฉริยะนั้นไม่ได้สร้างภาระให้กับระบบที่อยู่มากนัก แต่ยังมีปัญหาทางเทคนิคบางอย่างที่ต้องแก้ไขในส่วนอื่นๆ ของแอปพลิเคชันสแต็ก จำเป็นต้องอัปเดตกระเป๋าเงินเพื่อให้แน่ใจว่าพวกเขาไม่ได้เพียงแค่ส่งก๊าซ 21,000 รายการในการทำธุรกรรม แต่ที่สำคัญกว่านั้นเพื่อให้แน่ใจว่าด้านการรับการชำระเงินของกระเป๋าเงินไม่เพียงติดตามการโอน ETH จาก EOA เท่านั้น แต่ยังรวมถึง ETH ที่ส่งโดยรหัสสัญญาอัจฉริยะ แอปพลิเคชันที่อาศัยสมมติฐานของการเป็นเจ้าของที่อยู่ที่ไม่เปลี่ยนรูป (เช่น NFT ที่ห้ามสัญญาอัจฉริยะเพื่อบังคับใช้ค่าสิทธิ) จะต้องหาวิธีอื่นเพื่อให้บรรลุเป้าหมาย กระเป๋าเงินสัญญาอัจฉริยะจะทำให้บางสิ่งง่ายขึ้น โดยเฉพาะอย่างยิ่ง หากมีคนยอมรับเฉพาะโทเค็น ERC20 ที่ไม่ใช่ ETH พวกเขาจะสามารถใช้ผู้ชำระเงิน ERC-4337 เพื่อชำระค่าน้ำมันด้วยโทเค็นนั้นได้

ในทางกลับกัน ความเป็นส่วนตัวนำเสนอความท้าทายที่สำคัญอีกครั้งที่เรายังไม่ได้แก้ไขอย่างแท้จริง Tornado Cash ดั้งเดิมไม่ได้นำเสนอปัญหาเหล่านี้เนื่องจากไม่รองรับการโอนภายใน: ผู้ใช้สามารถฝากเข้าสู่ระบบและถอนออกได้เท่านั้น เมื่อคุณทำการถ่ายโอนภายในได้แล้ว ผู้ใช้จะต้องใช้รูปแบบที่อยู่ภายในของระบบความเป็นส่วนตัว ในทางปฏิบัติ "ข้อความการชำระเงิน" ของผู้ใช้จำเป็นต้องมี (i) "คีย์สาธารณะที่ใช้จ่ายเงิน" บางประเภท ซึ่งเป็นคำมั่นสัญญาของความลับที่ผู้รับสามารถใช้เพื่อใช้จ่าย และ (ii) ผู้ส่งจะส่งข้อความที่เข้ารหัสซึ่งมีเฉพาะ ผู้รับสามารถถอดรหัสวิธีที่จะช่วยให้ผู้รับค้นพบการชำระเงิน

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

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

การแปลงสามรายการและการกู้คืนคีย์

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

ค่าน้ำมันที่ไม่สมจริง: อันนี้พูดเพื่อตัวมันเอง

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

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

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

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

การพิสูจน์สามารถทำได้หลายวิธี:

1. อ่านการเข้าถึง L1 แบบอ่านอย่างเดียวโดยตรงใน L2 สามารถแก้ไข L2 เพื่อให้มีวิธีอ่านสถานะของ L1 ได้โดยตรง หากสัญญาที่เก็บคีย์อยู่บน L1 นี่หมายความว่าสัญญาใน L2 มีสิทธิ์เข้าถึงที่เก็บคีย์ "ฟรี"

2. สาขาแมร์เคิล สาขา Merkle สามารถพิสูจน์สถานะ L1 เป็น L2 หรือสถานะ L2 เป็น L1 หรือคุณสามารถรวมสองสถานะเข้าด้วยกันเพื่อพิสูจน์ส่วนของสถานะ L2 หนึ่งไปยังอีก L2 จุดอ่อนหลักของการพิสูจน์ Merkle คือต้นทุนก๊าซที่สูงเนื่องจากความยาวของการพิสูจน์: การพิสูจน์อาจต้องใช้ 5 kB แม้ว่าสิ่งนี้จะลดลงเหลือน้อยกว่า 1 kB ในอนาคตด้วยต้นไม้ Verkle

3. ZK-SNARK คุณสามารถลดต้นทุนข้อมูลได้โดยใช้ ZK-SNARK ของสาขา Merkle แทนสาขาเอง สามารถสร้างเทคนิคการรวมแบบออฟไลน์ (เช่น ตาม EIP-4337) เพื่อให้ ZK-SNARK เดียวตรวจสอบการพิสูจน์สถานะข้ามเชนทั้งหมดในบล็อกเดียว

4. ความมุ่งมั่นของ KZG L2 หรือโครงร่างที่สร้างขึ้นด้านบน สามารถแนะนำระบบการกำหนดแอดเดรสแบบลำดับที่อนุญาตให้การพิสูจน์สถานะภายในระบบนี้มีความยาวเพียง 48 ไบต์ เช่นเดียวกับ ZK-SNARK โครงร่างการพิสูจน์หลายชั้นสามารถรวมการพิสูจน์ทั้งหมดเหล่านี้เป็นการพิสูจน์เดียวสำหรับแต่ละบล็อก

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

ในการเพิ่มความเป็นส่วนตัวให้กับโครงร่างดังกล่าว เราเพียงต้องเข้ารหัสตัวชี้ จากนั้นทำการพิสูจน์ทั้งหมดใน ZK-SNARK:

ด้วยการทำงานที่มากขึ้น (เช่น การใช้งานนี้เป็นจุดเริ่มต้น) เรายังสามารถตัดความซับซ้อนส่วนใหญ่ของ ZK-SNARK และสร้างโครงร่างที่ใช้ KZG ได้ง่ายขึ้น

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

จำเป็นต้องอัปเดตโครงสร้างพื้นฐานสำรองจำนวนมาก

การใช้ ENS มีค่าใช้จ่ายสูง วันนี้ในเดือนมิถุนายน 2023 สิ่งต่างๆ ก็ไม่ได้แย่เกินไป: แม้ว่าค่าธรรมเนียมการทำธุรกรรมจะสูง แต่ก็เทียบได้กับค่าธรรมเนียมโดเมน ENS การลงทะเบียนกับ zuzalu.eth ทำให้ฉันเสียค่าใช้จ่ายประมาณ 27 ดอลลาร์ ซึ่ง 11 ดอลลาร์เป็นค่าธรรมเนียมการทำธุรกรรม แต่ถ้าเรามีตลาดกระทิงอีกแห่ง ค่าธรรมเนียมจะพุ่งสูงขึ้น แม้จะไม่มีการขึ้นราคา ETH แต่การคืนค่าธรรมเนียมน้ำมันเป็น 200 gwei จะเพิ่มค่าธรรมเนียมการทำธุรกรรมสำหรับการจดทะเบียนโดเมนเป็น $104 ดังนั้น หากเราต้องการให้ผู้คนใช้ ENS จริง ๆ โดยเฉพาะอย่างยิ่งสำหรับกรณีการใช้งาน เช่น โซเชียลมีเดียแบบกระจายอำนาจ ซึ่งผู้ใช้ขอลงทะเบียนเกือบฟรี (ค่าธรรมเนียมโดเมน ENS ไม่ใช่ปัญหา เนื่องจากแพลตฟอร์มเหล่านี้มีโดเมนย่อยสำหรับผู้ใช้) เราจำเป็นต้องมี ENS Runs บน L2 .

โชคดีที่ทีม ENS กำลังดำเนินการอยู่ และ ENS ใน L2 ก็กำลังเกิดขึ้นจริง! ERC-3668 (หรือที่เรียกว่า "มาตรฐาน CCIP") ร่วมกับ ENSIP-10 ให้วิธีการตรวจสอบโดเมนย่อย ENS บน L2 ใดๆ โดยอัตโนมัติ มาตรฐาน CCIP กำหนดให้มีการตั้งค่าสัญญาอัจฉริยะที่อธิบายวิธีการตรวจสอบหลักฐานข้อมูล L2 และชื่อโดเมน (เช่น ecc.eth สำหรับ Optinames) สามารถอยู่ภายใต้การควบคุมของสัญญาดังกล่าวได้ เมื่อสัญญา CCIP ควบคุม ecc.eth บน L1 แล้ว การเข้าถึง subdomain.ecc.eth บางส่วนจะเกี่ยวข้องกับการค้นหาและตรวจสอบสถานะ L2 ของการพิสูจน์โดยอัตโนมัติ (เช่น สาขา Merkle) ที่เก็บโดเมนย่อยนั้นๆ

การได้รับการพิสูจน์จริง ๆ แล้วเกี่ยวข้องกับการเข้าถึงชุดของ URL ที่จัดเก็บไว้ในสัญญา ซึ่งเป็นที่ยอมรับว่าให้ความรู้สึกเหมือนการรวมศูนย์ แม้ว่าฉันจะเถียงว่าจริง ๆ แล้วไม่ใช่ มันเป็นรูปแบบความน่าเชื่อถือแบบ 1 ใน 1 (การพิสูจน์ที่ไม่ถูกต้องจะถูกบล็อกโดย CCIP การยืนยัน ตรรกะในฟังก์ชันการโทรกลับของสัญญาระบุว่า ตราบใดที่มี URL ที่ส่งคืนหลักฐานที่ถูกต้อง ก็จะไม่มีปัญหา) รายการ URL นี้อาจมีหลายสิบ URL

งานของ ENS CCIP เป็นเรื่องราวความสำเร็จและควรได้รับการมองว่าเป็นสัญญาณว่าการปฏิรูปแบบถอนรากถอนโคนที่เราต้องการนั้นเป็นไปได้ แต่จำเป็นต้องมีการปฏิรูประดับแอปพลิเคชันเพิ่มเติม ตัวอย่างบางส่วนได้แก่:

Dapps จำนวนมากพึ่งพาผู้ใช้ในการจัดเตรียมลายเซ็นแบบออฟไลน์ สำหรับบัญชีภายนอก (EOA) เป็นเรื่องง่าย ERC-1271 เป็นวิธีมาตรฐานสำหรับกระเป๋าเงินสัญญาอัจฉริยะในการทำเช่นนี้ อย่างไรก็ตาม dapps จำนวนมากยังไม่รองรับ ERC-1271 พวกเขาจำเป็นต้องรองรับ

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

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

ไคลเอ็นต์แบบไลท์ (เช่น Helios) จะต้องตรวจสอบ L2 ไม่ใช่แค่ L1 ปัจจุบัน ไคลเอ็นต์แบบไลท์มุ่งเน้นไปที่การตรวจสอบความถูกต้องของส่วนหัว L1 (โดยใช้โปรโตคอลการซิงค์ไคลเอ็นต์แบบไลท์) และตรวจสอบความถูกต้องของสถานะ L1 และ Merkle fork ของธุรกรรมที่มาจากส่วนหัวของ L1 พรุ่งนี้ พวกเขายังต้องตรวจสอบการพิสูจน์สถานะ L2 ที่มาจากรูทสถานะที่จัดเก็บไว้ใน L1 (เวอร์ชันขั้นสูงกว่านี้จะดูที่การยืนยันล่วงหน้าของ L2)

กระเป๋าเงินจำเป็นต้องปกป้องทรัพย์สินและข้อมูล

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

เราเห็นสัญญาณแรกของโลกดังกล่าวด้วย Zupass ซึ่งเป็นระบบระบุตัวตนตาม ZK-SNARK ที่ใช้ใน Zuzalu ผู้ใช้มีรหัสส่วนตัวซึ่งใช้ในการยืนยันตัวตนของระบบ ซึ่งสามารถใช้ในการพิสูจน์ขั้นพื้นฐาน เช่น "พิสูจน์ว่าฉันเป็นผู้อาศัยใน Zuzalu แต่อย่าเปิดเผยว่าคนไหน" อย่างไรก็ตาม ระบบ Zupass ก็เริ่มสร้างแอปพลิเคชันอื่นๆ ขึ้นมาด้านบน โดยเฉพาะอย่างยิ่งแสตมป์ (POAP เวอร์ชัน Zupass)

หนึ่งในแสตมป์ Zupass มากมายของฉันที่พิสูจน์ว่าฉันเป็นสมาชิกที่น่าภาคภูมิใจของ Team Cat

คุณลักษณะสำคัญที่แสตมป์มีให้เหนือ POAP คือแสตมป์เป็นแบบส่วนตัว: คุณเก็บข้อมูลไว้ในเครื่อง และคุณจะพิสูจน์ตราประทับ (หรือการคำนวณบางอย่างบนนั้น) ให้พวกเขาเห็นเท่านั้น ถ้าคุณต้องการให้พวกเขามีข้อมูลนี้เกี่ยวกับคุณ แต่สิ่งนี้จะเพิ่มความเสี่ยง: หากคุณสูญเสียข้อมูลนี้ คุณจะสูญเสียตราประทับของคุณ

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

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

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

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

กลับไปที่คำถามประจำตัว

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

วิธีหนึ่งในการทำเช่นนี้คือการทำให้ ENS ระบุตัวตนของคุณ: บันทึก ENS ของคุณสามารถมีข้อมูลทั้งหมดนี้ได้ และถ้าคุณส่ง bob.eth (หรือ bob.ecc.eth หรือ...) ไปให้ใครบางคน พวกเขาจะสามารถค้นหาและเรียนรู้เกี่ยวกับ ทุกสิ่งที่จ่ายและโต้ตอบกับคุณ รวมถึงวิธีการตัดขวางที่ซับซ้อนมากขึ้นและการรักษาความเป็นส่วนตัว

อย่างไรก็ตาม วิธีการที่เน้น ENS เป็นศูนย์กลางนี้มีจุดอ่อนสองประการ:

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

คุณไม่สามารถมีชื่อที่ไม่น่าเชื่อถือที่ไม่น่าเชื่อถือ คุณสมบัติ UX ที่สำคัญของบล็อกเชนคือความสามารถในการส่งเหรียญไปยังผู้ที่ยังไม่ได้โต้ตอบกับเชน หากไม่มีฟังก์ชันดังกล่าว ก็จะเกิดปัญหาไก่กับไข่: การโต้ตอบกับเครือข่ายต้องเสียค่าธรรมเนียมการทำธุรกรรม และการจ่ายค่าธรรมเนียมต้อง... มีเหรียญอยู่แล้ว ที่อยู่ ETH รวมถึงที่อยู่สัญญาอัจฉริยะด้วย CREATE2 มีคุณสมบัตินี้ ชื่อ ENS ไม่ใช่เพราะหาก Bobs สองคนตัดสินใจว่าพวกเขาเป็น bob.ecc.eth นอกเครือข่าย ไม่มีทางที่จะเลือกได้ว่าจะใช้ชื่อใด

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

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

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

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

ขอขอบคุณเป็นพิเศษสำหรับ Dan Finlay, Karl Floersch, David Hoffman และทีม Scroll และ SoulWallet สำหรับคำติชม บทวิจารณ์ และคำแนะนำ