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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ฉันมีเหรียญบน Scroll และฉันต้องการจ่ายค่ากาแฟ (หาก "ฉัน" คือฉันซึ่งเป็นผู้เขียนบทความนี้ แปลว่า "กาแฟ" เป็นคำนามแฝงของ "ชาเขียว") คุณกำลังขายกาแฟให้ฉัน แต่คุณพร้อมที่จะรับเหรียญจากไทโกะเท่านั้น ทำอะไร?

โดยพื้นฐานแล้วมีสองวิธี:

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

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

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

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

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

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

ภาพรวมแผนผังของโครงร่างที่อยู่แบบซ่อนตัวที่เป็นนามธรรมโดยอิงตามการเข้ารหัสและ ZK-SNARK

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

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

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

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

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

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

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

• การเข้าถึง L1 แบบอ่านอย่างเดียวโดยตรงภายใน L2 คุณสามารถแก้ไข L2 เพื่อให้อ่านสถานะ L1 ได้โดยตรง หากสัญญาที่เก็บคีย์อยู่บน L1 นั่นหมายความว่าสัญญาภายใน L2 สามารถเข้าถึงที่เก็บคีย์ได้ "ฟรี"
• สาขาเมิร์เคิล สาขา Merkle สามารถพิสูจน์สถานะ L1 เป็น L2 หรือสถานะ L2 เป็น L1 หรือคุณสามารถรวมทั้งสองเพื่อพิสูจน์สถานะของ L2 หนึ่งไปยัง L2 อีกอันหนึ่งได้ จุดอ่อนหลักของการพิสูจน์ Merkle คือต้นทุนก๊าซที่สูงเนื่องจากความยาวการพิสูจน์: อาจอยู่ที่ 5 kB สำหรับการพิสูจน์ แม้ว่าจะลดลงเหลือ < 1 kB ในอนาคตเนื่องจาก ต้นไม้ Verkle
• ZK-SNARK คุณสามารถลดต้นทุนข้อมูลได้โดยใช้ ZK-SNARK ของสาขา Merkle แทนตัวสาขาเอง เป็นไปได้ที่จะสร้างเทคนิคการรวมกลุ่มแบบนอกเครือข่าย (เช่น ด้านบนของ EIP-4337) เพื่อให้ ZK-SNARK เดียวตรวจสอบการพิสูจน์สถานะแบบข้ามสายโซ่ทั้งหมดในบล็อก
• ความมุ่งมั่นของ KZG L2 หรือโครงร่างที่สร้างขึ้นจากด้านบนอาจแนะนำระบบการกำหนดที่อยู่ตามลำดับ ซึ่งทำให้การพิสูจน์สถานะภายในระบบนี้มีความยาวเพียง 48 ไบต์เท่านั้น เช่นเดียวกับ ZK-SNARK รูปแบบการป้องกันหลายรายการ สามารถรวมการพิสูจน์ทั้งหมดเหล่านี้ให้เป็นการพิสูจน์เดียวต่อบล็อก

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

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

มีงานมากขึ้น (เช่น. ใช้<a href="https://notes.ethereum.org/ @vbuterin /non_index_revealing_proof">สิ่งนี้ ทำงานเป็นจุดเริ่มต้น) นอกจากนี้เรายังสามารถดึงความซับซ้อนส่วนใหญ่ของ ZK-SNARK ออกไป และสร้างโครงร่างที่ใช้ KZG แบบเปลือยเปล่ามากขึ้นได้

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

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

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

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

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

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

• DApps จำนวนมากขึ้นอยู่กับผู้ใช้ที่ให้ลายเซ็นนอกเครือข่าย ด้วยบัญชีภายนอก (EOA) นี่เป็นเรื่องง่าย ERC-1271 มอบวิธีการที่เป็นมาตรฐานในการดำเนินการนี้สำหรับกระเป๋าเงินสัญญาอัจฉริยะ อย่างไรก็ตาม DApps จำนวนมากยังไม่รองรับ ERC-1271 พวกเขาจะต้อง
• DApps ที่ใช้ “นี่คือ EOA หรือไม่” การเลือกปฏิบัติระหว่างผู้ใช้และสัญญา (เช่น เพื่อป้องกันการโอนหรือบังคับใช้ค่าลิขสิทธิ์) จะถือเป็นการละเมิด โดยทั่วไป ฉันไม่แนะนำให้พยายามค้นหาวิธีแก้ปัญหาทางเทคนิคล้วนๆ ที่นี่ การค้นหาว่าการถ่ายโอนการควบคุมการเข้ารหัสโดยเฉพาะเป็นการถ่ายโอนความเป็นเจ้าของที่เป็นประโยชน์หรือไม่นั้นเป็นปัญหาที่ยากและอาจไม่สามารถแก้ไขได้หากปราศจากการแก้ไข กลไกที่ขับเคลื่อนโดยชุมชนนอกเครือข่าย เป็นไปได้มากว่าการสมัครจะต้องพึ่งพาการป้องกันการโอนน้อยลง และพึ่งพาเทคนิคต่างๆ เช่น ภาษี Harberger มากขึ้น
• จะต้องปรับปรุงวิธีที่กระเป๋าเงินโต้ตอบกับการใช้จ่ายและคีย์การเข้ารหัส ปัจจุบัน กระเป๋าเงินมักใช้ลายเซ็นที่กำหนดเพื่อสร้างคีย์เฉพาะแอปพลิเคชัน: การลงนาม nonce มาตรฐาน (เช่น แฮชของชื่อแอปพลิเคชัน) ด้วยคีย์ส่วนตัวของ EOA จะสร้างค่าที่กำหนดขึ้นซึ่งไม่สามารถสร้างได้หากไม่มีคีย์ส่วนตัว และดังนั้นจึงปลอดภัย ในแง่ทางเทคนิคล้วนๆ อย่างไรก็ตาม เทคนิคเหล่านี้ "ไม่ชัดเจน" สำหรับกระเป๋าสตางค์ ทำให้กระเป๋าสตางค์ไม่สามารถดำเนินการตรวจสอบความปลอดภัยระดับอินเทอร์เฟซผู้ใช้ได้ ในระบบนิเวศที่เติบโตเต็มที่ การลงนาม การเข้ารหัส และฟังก์ชันที่เกี่ยวข้องจะต้องได้รับการจัดการโดยกระเป๋าสตางค์อย่างชัดเจนยิ่งขึ้น
• ลูกค้ารายย่อย (เช่น Helios) จะต้องตรวจสอบ L2 และไม่ใช่แค่ L1 ปัจจุบัน ไคลเอ็นต์แบบ light มุ่งเน้นไปที่การตรวจสอบความถูกต้องของส่วนหัว L1 (โดยใช้ light client sync protocol) และการตรวจสอบสาขา Merkle ของสถานะ L1 และธุรกรรมที่ฝังรากอยู่ในส่วนหัว L1 พรุ่งนี้ พวกเขาจะต้องตรวจสอบหลักฐานของสถานะ L2 ที่รูทในรูทสถานะที่จัดเก็บไว้ใน L1 (เวอร์ชันขั้นสูงกว่านี้จะดูที่การยืนยันล่วงหน้าของ L2)

กระเป๋าเงินจะต้องรักษาความปลอดภัยทั้งทรัพย์สินและข้อมูล

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

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

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

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

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

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

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

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

กลับไปสู่ตัวตน

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

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

แต่แนวทางที่เน้น ENS นี้มีจุดอ่อนสองประการ:

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

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

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

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

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

ข้อสงวนสิทธิ์：

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