Bài viết mới của Buterin: Hướng dẫn chưa đầy đủ về địa chỉ lén lút

Tiêu đề gốc: "Hướng dẫn chưa đầy đủ về các địa chỉ lén lút"

Tác giả gốc: Vitalik Buterin

Bản tổng hợp gốc: Karen, Tin tức về tầm nhìn xa

Một trong những thách thức lớn nhất trong hệ sinh thái Ethereum hiện tại là quyền riêng tư. Theo mặc định, mọi thứ đi vào chuỗi khối công khai đều là công khai, có nghĩa là không chỉ tài sản và hoạt động giao dịch mà còn cả tên ENS, POAP, NFT và mã thông báo gắn kết linh hồn, cùng nhiều thứ khác. Sử dụng nhiều ứng dụng Ethereum có nghĩa là phần lớn hoạt động của bạn sẽ được hiển thị cho bất kỳ ai khác xem và phân tích.

Chúng ta cần cải thiện tình trạng này. Tuy nhiên, cho đến nay, cuộc thảo luận về việc cải thiện quyền riêng tư chủ yếu xoay quanh một trường hợp sử dụng cụ thể: chuyển ETH và mã thông báo ERC20 chính thống để bảo vệ quyền riêng tư. Bài đăng này sẽ mô tả cơ chế và trường hợp sử dụng của một loại công cụ khác có thể cải thiện trạng thái quyền riêng tư của Ethereum trong nhiều bối cảnh khác, cụ thể là khái niệm “địa chỉ ẩn”.

Hệ thống địa chỉ lén lút là gì?

Giả sử Alice muốn chuyển tài sản cho Bob, có thể là một lượng tiền điện tử nhất định (chẳng hạn như 1 ETH, 500 RAI) hoặc NFT. Khi Bob nhận được tài sản, anh ấy không muốn người khác biết mình là người nhận tài sản đó. Không thể che giấu sự thật rằng một giao dịch chuyển tiền đã diễn ra, đặc biệt nếu giao dịch chuyển tiền đó đến một NFT chỉ có một bản sao tồn tại trên chuỗi, mặc dù việc giấu ai là người nhận có thể khả thi hơn.

Điều Alice và Bob muốn hơn là một hệ thống quy trình thanh toán, nghĩa là Bob gửi cho Alice (hoặc hỗ trợ tên miền ENS) một số loại mã hóa "Địa chỉ", điều này chỉ thông tin thôi cũng đủ để Alice (hoặc bất kỳ ai khác) gửi cho anh ta một tài sản và nó gần giống với quy trình thanh toán hiện tại.

Điều quan trọng cần lưu ý là quyền riêng tư này hoàn toàn khác với quyền riêng tư do Tornado Cash cung cấp. Tornado Cash có thể che giấu việc chuyển giao các tài sản có thể thay thế chính thống như ETH hoặc ERC-20 chính (thường được sử dụng để gửi riêng cho chính bạn), nhưng lại rất yếu trong việc thêm quyền riêng tư cho các giao dịch chuyển khoản ERC20 ít được biết đến hơn và không thể thêm quyền riêng tư nào cho chuyển khoản NFT.

Quy trình thanh toán thông thường bằng tiền điện tử như đã đề cập ở trên sẽ bổ sung thêm quyền riêng tư, nghĩa là không ai có thể biết rằng người nhận tài sản là Bob và quy trình làm việc không thay đổi.

Địa chỉ ẩn là địa chỉ có thể được tạo bởi Alice hoặc Bob, nhưng chỉ có thể được do Bob điều khiển. Bob tạo khóa chi tiêu, giữ bí mật và sau đó sử dụng khóa đó để tạo địa chỉ meta ẩn. Anh ta chuyển địa chỉ meta này cho Alice (hoặc đăng ký nó trên ENS). Alice có thể thực hiện các phép tính trên siêu địa chỉ này để tạo ra một địa chỉ ẩn thuộc về Bob. Sau đó, Alice có thể gửi bất kỳ tài sản nào cô ấy muốn đến địa chỉ này và Bob sẽ có toàn quyền kiểm soát chúng. Trong quá trình chuyển giao, Alice xuất bản một số dữ liệu được mã hóa bổ sung (khóa công khai tạm thời) trên chuỗi để giúp Bob phát hiện ra rằng địa chỉ này thuộc về anh ta.

Một cách khác để xem xét vấn đề này là: Địa chỉ ẩn cung cấp các thuộc tính bảo mật giống như của Bob, tạo ra một địa chỉ mới cho mỗi giao dịch nhưng không yêu cầu bất kỳ Tương tác nào của Bob.

Quy trình làm việc hoàn chỉnh của sơ đồ địa chỉ ẩn như sau:

1.Bob tạo khóa chi tiêu gốc (m) và địa chỉ meta ẩn (M).

2.Bob thêm bản ghi ENS để đăng ký (M) địa chỉ meta ẩn bob.eth cho bob.eth.

3. Chúng ta giả định rằng Alice biết địa chỉ của Bob là bob.eth. Alice tra cứu địa chỉ meta tàng hình (M) của Bob trên ENS.

4.Alice tạo một khóa tạm thời mà chỉ cô ấy biết và cô ấy chỉ có thể sử dụng một lần (để tạo địa chỉ ẩn cụ thể này).

5.Alice sử dụng thuật toán kết hợp khóa tạm thời của cô ấy với địa chỉ meta của Bob để tạo địa chỉ ẩn. Bây giờ cô ấy có thể gửi tài sản đến địa chỉ này.

6.Alice cũng tạo khóa công khai tạm thời của mình và xuất bản nó lên cơ quan đăng ký khóa công khai tạm thời (điều này có thể được thực hiện trong cùng một giao dịch với giao dịch đầu tiên gửi nội dung đến địa chỉ ẩn này).

7. Để Bob phát hiện ra địa chỉ ẩn thuộc về mình, Bob cần quét sổ đăng ký khóa công khai tạm thời để tìm toàn bộ danh sách khóa công khai tạm thời được xuất bản bởi bất kỳ ai kể từ lần quét cuối cùng của anh ấy.

8. Đối với mỗi khóa chung tạm thời, Bob cố gắng tạo một địa chỉ ẩn bằng cách kết hợp nó với khóa chi tiêu gốc của mình và kiểm tra xem có bất kỳ tài sản nào trong địa chỉ đó hay không. Nếu có, Bob tính toán mã chi tiêu cho địa chỉ đó và ghi nhớ nó.

Tất cả đều dựa vào hai cách sử dụng giả mạo mật khẩu. Trước tiên, chúng ta cần một cặp thuật toán để tạo bí mật chung: một thuật toán sử dụng khóa tạm thời của Alice và địa chỉ meta của Bob và một thuật toán khác sử dụng khóa chi tiêu gốc của Bob và khóa chung tạm thời của Alice. Điều này có thể được thực hiện theo nhiều cách khác nhau; Diffie-Hellman Trao đổi khóa, một trong những thứ đã xây dựng nên lĩnh vực mật mã hiện đại, thực hiện chính xác điều đó.

Nhưng chỉ chia sẻ bí mật là chưa đủ: nếu chúng ta chỉ tạo khóa riêng từ bí mật chung thì cả Alice và Bob đều có thể sử dụng từ địa chỉ này. Chúng tôi cũng đã thêm cơ chế làm mù khóa: trong một cặp thuật toán, Bob có thể kết hợp bí mật được chia sẻ với khóa chi tiêu gốc của anh ấy và Alice có thể kết hợp bí mật được chia sẻ với địa chỉ meta của Bob, để sau đó Alice có thể tạo một địa chỉ ẩn và Bob có thể tạo khóa chi tiêu cho địa chỉ ẩn đó mà không cần tạo liên kết công khai giữa địa chỉ ẩn và địa chỉ meta của Bob (hoặc giữa địa chỉ ẩn này với địa chỉ ẩn khác).

Sử dụng mật mã đường cong elip để ẩn địa chỉ

Ẩn địa chỉ bằng mật mã đường cong elip ban đầu là Được Peter Todd giới thiệu vào năm 2014trong bối cảnh Bitcoin. Đây là cách công nghệ này hoạt động:

· Bob tạo khóa (m) và tính M = G * m, trong đó G là điểm tạo được công nhận của đường cong elip. Địa chỉ meta ẩn là (M).

· Alice tạo khóa tạm thời (r) và công bố khóa chung tạm thời R = G * r.

· Alice có thể tính khóa chung S = M * r và Bob cũng có thể tính khóa chung S = m * R.

 ·Nói chung, trong Bitcoin và Ethereum (bao gồm cả các tài khoản ERC-4337 được thiết kế phù hợp), địa chỉ là một hàm băm chứa khóa chung được sử dụng để xác minh các giao dịch từ địa chỉ đó. Vì vậy, nếu bạn tính khóa chung, bạn có thể tính địa chỉ. Để tính khóa chung, Alice hoặc Bob có thể tính P = M + G * hash(S) 

Để tính khóa riêng của địa chỉ, Bob có thể tính p = m + hash(S)   ; 

Điều này đáp ứng tất cả các yêu cầu của chúng tôi ở trên và rất đơn giản.

Thậm chí còn có một EIP cố gắng xác định tiêu chuẩn địa chỉ ẩn cho Ethereum vừa hỗ trợ phương pháp này vừa cho phép người dùng có chỗ để phát triển các phương pháp tiếp cận khác (ví dụ: hỗ trợ Bob có khóa chi tiêu và xem riêng biệt hoặc sử dụng mật mã khác nhau để đạt được lượng tử -chống lại an ninh). Bây giờ bạn có thể đang nghĩ: địa chỉ ẩn không quá khó, kiến thức lý thuyết đã vững chắc và việc áp dụng chỉ là một chi tiết triển khai. Tuy nhiên, vấn đề là việc triển khai thực sự hiệu quả đòi hỏi một số chi tiết triển khai quan trọng.

Địa chỉ ẩn và phí giao dịch thanh toán

Giả sử ai đó gửi cho bạn NFT. Nếu bạn muốn đảm bảo quyền riêng tư, họ sẽ gửi nó đến địa chỉ ẩn mà bạn kiểm soát. Ví của bạn sẽ tự động khám phá địa chỉ sau khi quét chuỗi để tìm khóa chung tạm thời. Bây giờ bạn có thể tự do chứng minh quyền sở hữu NFT của mình hoặc chuyển nó cho người khác. Nhưng có một vấn đề là số dư ETH trong tài khoản bằng 0 nên phí giao dịch cũng không thể thanh toán được. Ngay cả người trả tiền mã thông báo ERC-4337 cũng sẽ không hoạt động vì chúng chỉ áp dụng cho mã thông báo ERC20 có thể thay thế được. Và bạn không thể gửi ETH đến nó từ ví chính của mình vì sau đó bạn tạo một liên kết hiển thị công khai, điều đó có nghĩa là không có quyền riêng tư.

Có một cách đơn giản để giải quyết vấn đề này: chỉ cần sử dụng ZK-SNARK để chuyển tiền để trả phí. Nhưng việc này sẽ tiêu tốn rất nhiều gas. Chỉ cần một lần chuyển sẽ tiêu tốn thêm hàng trăm ngàn gas.

Một cách tiếp cận khác thông minh hơn liên quan đến việc tin tưởng vào các công cụ tổng hợp giao dịch chuyên biệt (các công cụ tìm kiếm theo thuật ngữ MEV). Các công cụ tổng hợp này sẽ cho phép người dùng thanh toán một lần để mua một bộ “vé” có thể được sử dụng để thanh toán cho các giao dịch trên chuỗi. Khi người dùng cần sử dụng NFT trong một địa chỉ ẩn không chứa gì khác, họ sẽ cung cấp một trong các vé cho đơn vị tổng hợp, sử dụng Mã hóa mù Chaumian. Đây là giao thức ban đầu được sử dụng trong các chương trình tiền điện tử bảo vệ quyền riêng tư tập trung được đề xuất vào những năm 1980 và 1990. Người tìm kiếm chấp nhận vé và liên tục đưa giao dịch vào gói của họ miễn phí cho đến khi giao dịch được chấp nhận thành công trong một khối.

Địa chỉ ẩn và khóa chi tiêu và xem riêng biệt

Giả sử rằng thay vì có một "khóa chi tiêu gốc" chính thực hiện mọi việc, Bob muốn có một khóa chi tiêu gốc và khóa xem riêng biệt. Phím xem này có thể xem tất cả các địa chỉ ẩn của Bob, nhưng không thể thực hiện chi tiêu.

Trong thế giới đường cong elip, điều này có thể được giải quyết bằng cách sử dụng một thủ thuật mã hóa rất đơn giản:

· Địa chỉ meta của Bob (M) hiện có dạng (K, V), mã hóa G * k và G * v, trong đó k là khóa chi tiêu và v là khóa xem.

· Khóa dùng chung lúc này là S = V * r = v * R, trong đó r vẫn là khóa tạm thời của Alice và R vẫn là khóa chung tạm thời do Alice cấp.

· Khóa chung của địa chỉ ẩn là P = K + G * hash(S), và khóa riêng là p = k + hash(S).

Bước đầu tiên (tạo bí mật chung) sử dụng khóa xem và bước thứ hai (thuật toán song song của Alice và Bob để tạo địa chỉ ẩn và khóa riêng của nó) sử dụng khóa chi tiêu Root.

Điều này có nhiều trường hợp sử dụng. Ví dụ: nếu Bob muốn nhận POAP, thì Bob có thể cung cấp khóa xem cho ví POAP của mình (hoặc thậm chí là giao diện web kém an toàn hơn) để quét chuỗi và xem tất cả POAP của mình mà không cần tốn tiền cho giao diện. POAP.

Địa chỉ ẩn và quét dễ dàng

Để quét toàn bộ bộ khóa chung tạm thời dễ dàng hơn, một kỹ thuật là thêm nhãn xem cho mỗi khóa chung tạm thời. Một cách để thực hiện điều này trong cơ chế trên là đặt nhãn dạng xem thành một byte của bí mật chung (ví dụ: tọa độ x của S modulo 256 hoặc byte đầu tiên của hàm băm (S).

Bằng cách này, Bob chỉ cần thực hiện một phép nhân đường cong elip cho mỗi khóa chung tạm thời để tính toán bí mật chung, việc quét này cũng dễ dàng hơn do có thẻ xem

Địa chỉ ẩn và bảo mật kháng lượng tử

Sơ đồ trên dựa trên các đường cong elip, nhưng mặc dù sơ đồ này hoạt động tốt nhưng rất tiếc là nó lại dễ bị máy tính lượng tử tấn công. là hai ứng cử viên tự nhiên: mạng đường cong elip

Cognate đường cong Elliptic là một cấu trúc toán học rất khác dựa trên các đường cong elip với các thuộc tính tuyến tính cho phép chúng ta sử dụng nó với các tính năng trên. Một thủ thuật mã hóa tương tự đã được thực hiện, nhưng khéo léo tránh việc xây dựng các nhóm tuần hoàn có thể dễ bị tổn thương trước các cuộc tấn công logarit rời rạc trên máy tính lượng tử

Chủ yếu dựa trên mật mã tương đồng. Điểm yếu là toán học cơ bản rất phức tạp của nó và nguy cơ xảy ra các cuộc tấn công tiềm ẩn bên trong điều này. độ phức tạp Một số giao thức dựa trên cùng nguồn gốc (mật mã) đã bị tấn công vào năm ngoái, Nhưng các giao thức khác vẫn an toàn Ưu điểm chính của tính tương đồng là kích thước khóa tương đối nhỏ và khả năng di chuyển trực tiếp của nhiều phương pháp dựa trên đường cong elip

Một đồng phân 3 trong CSIDH

Mạng là một cấu trúc mật mã rất khác, dựa trên toán học đơn giản hơn so với các phép đẳng cấu của đường cong elip và có khả năng thực hiện một số việc rất mạnh mẽ (ví dụ: Mã hóa đồng cấu hoàn toàn). Lược đồ địa chỉ ẩn có thể được xây dựng trên mạng, mặc dù việc thiết kế lược đồ tốt nhất là một câu hỏi mở. Tuy nhiên, cấu trúc dựa trên mạng có xu hướng có kích thước khóa lớn hơn.

Đầy đủ Mã hóa đồng cấu, ứng dụng của mạng. FHE cũng có thể được sử dụng để hỗ trợ giao thức địa chỉ ẩn theo một cách khác: giúp Bob thuê ngoài tính toán để kiểm tra xem toàn bộ chuỗi có chứa địa chỉ ẩn của nội dung hay không mà không tiết lộ khóa xem của anh ấy.

Cách tiếp cận thứ ba là xây dựng các địa chỉ tàng hình từ các hộp đen nguyên thủy thông thường. Phần tạo khóa dùng chung của lược đồ ánh xạ trực tiếp tới Trao đổi khóa, Phần này là một thành phần quan trọng trong hệ thống mật mã khóa công khai. Phần khó hơn là thuật toán song song cho phép Alice chỉ tạo địa chỉ ẩn (chứ không phải khóa chi tiêu) và cho phép Bob tạo khóa chi tiêu.

Thật không may, bạn không thể xây dựng một địa chỉ ẩn bằng cách sử dụng các thành phần đơn giản hơn những gì cần thiết để xây dựng một hệ thống mật mã khóa công khai. Có một bằng chứng đơn giản cho thấy có thể xây dựng một hệ thống mã hóa khóa công khai bằng cách sử dụng sơ đồ địa chỉ ẩn. Nếu Alice muốn mã hóa tin nhắn cho Bob, cô ấy có thể gửi N giao dịch, mỗi giao dịch được gửi đến địa chỉ ẩn của Bob hoặc địa chỉ ẩn của riêng cô ấy và Bob có thể xem giao dịch nào anh ấy đã nhận được để đọc tin nhắn. . Điều này rất quan trọng, trong các bằng chứng toán học, bạn không thể thực hiện mật mã khóa công khai chỉ bằng hàm băm, bạn có thể làm điều đó chỉ bằng hàm băm Bằng chứng không có kiến thức, do đó, không thể thực hiện các địa chỉ ẩn chỉ bằng hàm băm.

Đây thực sự là một cách tiếp cận sử dụng các thành phần tương đối đơn giản: bằng chứng không có kiến thức, có thể bao gồm hàm băm và mã hóa khóa công khai (ẩn khóa). Địa chỉ meta của Bob là khóa mã hóa công khai cộng với hàm băm h = hash(x) và khóa chi tiêu của anh ấy là khóa giải mã tương ứng cộng với x. Để tạo một địa chỉ ẩn, Alice tạo một giá trị c và công bố mã hóa c mà Bob có thể đọc được làm khóa chung tạm thời của cô ấy. Bản thân địa chỉ đó là một tài khoản ERC-4337 có mã là A Cần có bằng chứng không có kiến thức để xác minh giao dịch, chứng minh quyền sở hữu các giá trị x và c sao cho k = hash(hash(x), c) (trong đó k là một phần của mã tài khoản). Biết x và c, Bob có thể tự mình xây dựng lại địa chỉ và mã hóa.

Việc mã hóa (c) sẽ không cho bất kỳ ai khác ngoại trừ Bob biết bất kỳ thông tin nào và (k) là hàm băm hầu như không tiết lộ gì về c  Bản thân mã ví chỉ chứa (k) và (c) là riêng tư có nghĩa là (k) không thể truy ngược lại (h).

Tuy nhiên, điều này đòi hỏi phải có STARK. Cuối cùng, tôi nghĩ thế giới Ethereum hậu lượng tử có thể sẽ liên quan đến các ứng dụng sử dụng nhiều STARK, vì vậy tôi ủng hộ Các giao thức tổng hợp giống như giao thức được mô tả ở đây kết hợp tất cả các STARK này thành một STARK đệ quy để tiết kiệm dung lượng.

Địa chỉ ẩn và khả năng phục hồi xã hội cùng nhiều ví L2

Tôi đã quan tâm đến Xã hội Ví khôi phục Ví khôi phục xã hội có cơ chế đa chữ ký có khóa có thể được chia sẻ giữa một số tổ hợp tổ chức, thiết bị khác của bạn và bạn bè. Nếu bạn mất khóa chính thì hầu hết các khóa đều cho phép bạn khôi phục quyền truy cập tài khoản.

Tuy nhiên, ví khôi phục xã hội không kết hợp tốt với các địa chỉ ẩn: nếu bạn phải khôi phục tài khoản của mình (thay đổi khóa riêng kiểm soát tài khoản đó), bạn cũng phải thực hiện Một số bước để thay đổi logic xác minh tài khoản của N ví tàng hình của bạn, sẽ yêu cầu N giao dịch, với chi phí cao, tiện lợi và riêng tư.

Có những lo ngại tương tự về khả năng phục hồi xã hội và sự tương tác của nhiều giao thức L2: nếu bạn có tài khoản trên Optimism, Arbitrum, StarkNet, Scroll, Polygon, vì lý do Mở rộng quy mô Với hàng tá phiên bản song song và bạn có tài khoản trên mỗi phiên bản, việc thay đổi khóa có thể là một thao tác rất phức tạp.

Thay đổi khóa cho nhiều tài khoản trong nhiều chuỗi là một công việc to lớn.

Có lẽ bạn có thể sử dụng một số phần mềm tự động để di chuyển tài sản sang các khoảng thời gian ngẫu nhiên trong thời gian hai tuần span Di chuyển đến một địa chỉ ẩn mới để giảm hiệu quả của việc tương quan dựa trên thời gian. Nhưng nó còn lâu mới hoàn hảo. Một giải pháp thay thế là bí mật chia sẻ khóa gốc giữa những người giám hộ thay vì sử dụng tính năng khôi phục hợp đồng thông minh. Tuy nhiên, điều này sẽ loại bỏ khả năng vô hiệu hóa người giám hộ để giúp khôi phục sức mạnh tài khoản của bạn, do đó sẽ có rủi ro lâu dài.

Một cách tiếp cận phức tạp hơn liên quan đến bằng chứng không có kiến thức. Điều này cho phép nhiều tài khoản, thậm chí trên nhiều giao thức L2, được kiểm soát bởi một giá trị k duy nhất ở đâu đó (trên chuỗi cơ sở hoặc một số L2), trong đó việc thay đổi giá trị đó là đủ để thay đổi quyền sở hữu của tất cả các tài khoản mà không làm rò rỉ Liên kết của bạn giữa Nhiều tài khoản.

Kết luận

Địa chỉ ẩn cơ bản hiện tại có thể được triển khai nhanh chóng và cải thiện đáng kể quyền riêng tư của người dùng trên Ethereum. Tôi nghĩ ví nên bắt đầu chuyển sang mô hình nhiều địa chỉ gốc hơn vì các lý do khác liên quan đến quyền riêng tư (ví dụ: tạo địa chỉ mới cho mỗi ứng dụng mà bạn tương tác có thể là một tùy chọn).

Tuy nhiên, địa chỉ ẩn có một số vấn đề về khả năng sử dụng lâu dài, chẳng hạn như khó khăn trong việc phục hồi xã hội. Về lâu dài, những vấn đề này có thể giải quyết được, nhưng hệ sinh thái địa chỉ ẩn dường như phụ thuộc rất nhiều vào bằng chứng không có kiến thức.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia