Giới thiệu loại coin

Lộ trình của Ethereum kết hợp một công nghệ mở rộng quy mô được gọi là Lấy mẫu sẵn có dữ liệu (DAS) 6. DAS giới thiệu<a href="https://notes.ethereum.org/ @djrtwo /das-requirements">yêu cầu mới 4 vào ngăn xếp mạng của Ethereum, đòi hỏi phải triển khai các giao thức mạng chuyên dụng 7 . Một <a href="https://notes.ethereum.org/@dankrad /S-Kademlia-DAS"> giao thức nổi bật đề xuất 4 sử dụng Bảng băm phân tán (DHT) dựa trên Kademlia 2 để lưu trữ và truy xuất các mẫu dữ liệu.

Tuy nhiên, DHT 4 dễ bị tấn công Sybil: Kẻ tấn công kiểm soát một số lượng lớn nút DHT có thể khiến mẫu DAS không khả dụng. Để chống lại mối đe dọa này, một lớp mạng có độ tin cậy cao có thể được thiết lập, chỉ bao gồm các trình xác thực chuỗi đèn hiệu. Biện pháp bảo mật như vậy làm tăng đáng kể rào cản đối với những kẻ tấn công, vì giờ đây chúng phải đặt cược ETH của chính mình để tấn công DHT.

Trong bài đăng này, chúng tôi giới thiệu bằng chứng về giao thức của trình xác thực, cho phép những người tham gia DHT chứng minh rằng họ là trình xác thực Ethereum mà không cần biết gì.

Động cơ: Tấn công “ẩn mẫu” vào DAS

Trong phần này, chúng tôi thúc đẩy hơn nữa bằng chứng về giao thức của trình xác thực bằng cách mô tả một cuộc tấn công Sybil chống lại Lấy mẫu tính khả dụng của dữ liệu.

Giao thức DAS xoay quanh trình tạo khối để đảm bảo rằng dữ liệu khối được cung cấp để khách hàng có thể tìm nạp chúng. Các phương pháp hiện tại liên quan đến việc phân vùng dữ liệu thành các mẫu và những người tham gia mạng chỉ tìm nạp các mẫu liên quan đến sở thích của họ.

)

Hãy xem xét một tình huống trong đó kẻ tấn công Sybil muốn ngăn những người tham gia mạng tìm nạp mẫu từ nút nạn nhân, nút này chịu trách nhiệm cung cấp mẫu. Như được mô tả trong hình trên, kẻ tấn công tạo ra nhiều ID nút gần với ID nút của nạn nhân. Bằng cách bao quanh nút của nạn nhân bằng các nút riêng của họ, kẻ tấn công cản trở khách hàng khám phá nút nạn nhân, vì các nút xấu sẽ cố tình che giấu thông tin về sự tồn tại của nạn nhân.

Để biết thêm thông tin về các cuộc tấn công Sybil như vậy, hãy xem tài liệu nghiên cứu gần đây số 2 về các cuộc tấn công DHT Eclipse. Hơn nữa, <a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS#SKademlia-modifications">Dankrad Đề xuất giao thức mạng DAS 8 mô tả cách giao thức S/Kademlia DHT gặp phải các cuộc tấn công như vậy và cho thấy sự cần thiết phải có bằng chứng về giao thức xác thực.

Bằng chứng của người xác thực

Cuộc tấn công trên thúc đẩy sự cần thiết phải có bằng chứng về giao thức của trình xác thực: Nếu chỉ những người xác thực mới có thể tham gia DHT, thì kẻ tấn công muốn thực hiện cuộc tấn công Sybil cũng phải đặt cược một lượng lớn ETH.

Bằng cách sử dụng bằng chứng về giao thức trình xác thực, chúng tôi đảm bảo rằng chỉ những người xác thực chuỗi beacon mới có thể tham gia DHT và mỗi người xác thực sẽ có một danh tính DHT duy nhất.

Hơn nữa, để có khả năng phục hồi DoS của trình xác thực, chúng tôi cũng hướng đến việc ẩn danh tính của các trình xác thực trên lớp mạng. Nghĩa là, chúng tôi không muốn kẻ tấn công có thể biết nút DHT nào tương ứng với trình xác thực nào.

Để hoàn thành các mục tiêu này, bằng chứng về giao thức của trình xác thực phải đáp ứng các yêu cầu sau:

• Tính duy nhất: Mỗi trình xác nhận chuỗi beacon phải có khả năng lấy được một cặp khóa duy nhất. Thuộc tính này không chỉ hạn chế số lượng nút mà kẻ tấn công Sybil có thể tạo mà còn cho phép những người tham gia mạng trừng phạt cục bộ các nút hoạt động sai bằng cách đưa vào danh sách chặn cặp khóa dẫn xuất của chúng.
• Quyền riêng tư: Đối thủ không thể biết được trình xác thực nào tương ứng với khóa công khai dẫn xuất cụ thể
• Thời gian xác minh: Quá trình xác minh của giao thức phải hiệu quả, mất ít hơn 200 mili giây cho mỗi nút, cho phép mỗi nút học ít nhất năm nút mới mỗi giây

Bằng chứng về giao thức của trình xác thực như vậy sẽ được Bob sử dụng trong quá trình thiết lập kết nối trong lớp DHT, để Alice biết rằng cô ấy đang nói chuyện với người xác thực.

Bằng chứng về giao thức Trình xác thực

Bằng chứng về giao thức xác thực của chúng tôi thực sự là một sơ đồ thông tin xác thực ẩn danh đơn giản. Mục tiêu của nó là cho phép Alice tạo ra một khóa dẫn xuất duy nhất, được ký hiệu là D, nếu và chỉ nếu cô ấy là người xác thực. Sau đó, Alice sử dụng khóa dẫn xuất D này trong lớp mạng.

Khi thiết kế giao thức này, mục tiêu của chúng tôi là tạo ra một giải pháp vừa dễ thực hiện vừa dễ phân tích, đảm bảo đáp ứng các yêu cầu đã nêu một cách hiệu quả.

Tổng quan về giao thức

Giao thức sử dụng giao thức con chứng minh tư cách thành viên, trong đó Alice chứng minh cô ấy là người xác nhận bằng cách chứng minh kiến thức về tiền ảnh băm bí mật bằng cách sử dụng bằng chứng ZK. Sau đó, Alice xây dựng một cặp khóa duy nhất bắt nguồn từ tiền ảnh băm bí mật đó.

Giao thức con chứng minh tư cách thành viên có thể được khởi tạo thông qua các phương pháp khác nhau. Trong bài đăng này, chúng tôi hiển thị một giao thức sử dụng cây Merkle và giao thức thứ hai sử dụng tra cứu.

Mặc dù cả hai phương pháp đều cho thấy hiệu quả có thể chấp nhận được nhưng chúng có những điểm cân bằng rõ ràng. Cây Merkle dựa vào các hàm băm thân thiện với SNARK như Poseidon (có thể được coi là hàm băm thử nghiệm). Mặt khác, các giao thức tra cứu hiệu quả dựa vào thiết lập đáng tin cậy có kích thước bằng với kích thước của bộ trình xác thực (hiện có 700 nghìn trình xác thực nhưng đang tăng lên).

Bây giờ hãy đi sâu vào các giao thức:

Cách tiếp cận số 1: Cây Merkle

Cây Merkle đã được sử dụng rộng rãi để chứng minh tư cách thành viên (ví dụ: xem Semaphore 3). Đây là không gian cân bằng khi thiết kế bằng chứng thành viên bằng cây Merkle:

• Tích cực: Không cần thiết lập đáng tin cậy
• Tích cực: Đơn giản dễ hiểu
• Tiêu cực: Dựa vào các hàm băm thân thiện với SNARK như Poseidon
• Tiêu cực: Tạo bằng chứng chậm hơn

Dưới đây chúng tôi mô tả bằng chứng về giao thức xác thực dựa trên cây Merkle:

Giao thức bằng chứng xác nhận sử dụng cây Merkle

)

Khi kết thúc giao thức, Alice có thể sử dụng D trong DHT để ký các tin nhắn và lấy danh tính nút DHT duy nhất của mình.

Bây giờ chúng ta hãy xem xét một giải pháp phức tạp hơn một chút nhưng hiệu quả hơn nhiều bằng cách sử dụng tra cứu.

Cách tiếp cận số 2: Tra cứu

Đây là không gian cân bằng của việc sử dụng 2 giao thức tra cứu như Caulk 2:

• Tích cực: Tạo bằng chứng cực kỳ hiệu quả (sử dụng giai đoạn tiền xử lý)
• Tích cực: Giao thức có thể được điều chỉnh để sử dụng hàm băm thông thường thay vì Poseidon
• Tiêu cực: Yêu cầu thiết lập đáng tin cậy có kích thước lớn (lý tưởng nhất là bằng kích thước của trình xác thực)

Dưới đây chúng tôi mô tả bằng chứng cụ thể về giao thức xác thực:

Bằng chứng về giao thức xác thực bằng cách sử dụng tra cứu

Giống hệt như cách tiếp cận của Merkle, mỗi trình xác thực tôi đăng ký một giá trị pi mới trên blockchain sao cho:

Hiệu quả

Chúng tôi đã đo điểm chuẩn thời gian chạy của giao thức chứng minh tư cách thành viên của mình (liên kết 6 đến mã điểm chuẩn 5) về mặt tạo và xác minh bằng chứng. Lưu ý rằng mặc dù bằng chứng thành viên chỉ là một phần trong giao thức bằng chứng xác thực của chúng tôi nhưng chúng tôi hy vọng nó sẽ chiếm ưu thế trong thời gian chạy tổng thể.

Dưới đây, chúng tôi cung cấp kết quả điểm chuẩn cho bằng chứng tư cách thành viên cây merkle bằng cách sử dụng hệ thống bằng chứng Halo2 với IPA làm sơ đồ cam kết đa thức. IPA là một sơ đồ chậm hơn KZG nhưng nó không yêu cầu thiết lập đáng tin cậy để tối đa hóa lợi thế của phương pháp tiếp cận cây merkle.

Chúng tôi nhận thấy rằng cả thời gian của người chứng minh và người kiểm chứng đều phù hợp với yêu cầu về hiệu quả của chúng tôi. Vì lý do này, chúng tôi đã quyết định không đánh giá phương pháp tiếp cận dựa trên Caulk vì hiệu suất của nó được kỳ vọng sẽ tốt hơn đáng kể ở tất cả các hạng mục (đặc biệt là thời gian của người chứng minh và kích thước bằng chứng).

Điểm chuẩn được thu thập trên máy tính xách tay chạy trên Intel i7-8550U (CPU 5 năm tuổi).

Cuộc thảo luận

Danh tính luân phiên

Thuộc tính duy nhất của bằng chứng về giao thức xác thực đảm bảo rằng mỗi người tham gia mạng sở hữu một cặp khóa dẫn xuất riêng biệt. Tuy nhiên, đối với một số giao thức mạng nhất định, việc cho phép người xác thực có danh tính luân phiên có thể có lợi, trong đó các khóa dẫn xuất của họ thay đổi định kỳ, có thể là hàng ngày.

Trong trường hợp như vậy, nếu Eve cư xử không đúng mực vào một ngày cụ thể, Alice có thể đưa cô ấy vào danh sách chặn vào ngày đó. Tuy nhiên, vào ngày hôm sau, Eve có thể tạo khóa dẫn xuất mới, khóa này không nằm trong danh sách chặn. Nếu chúng tôi muốn có thể đưa những người xác thực vào danh sách chặn vĩnh viễn dựa trên danh tính luân phiên của họ, chúng tôi sẽ cần một sơ đồ thông tin xác thực ẩn danh nâng cao hơn như SNARKBlock 1.

Tại sao không sử dụng khóa chung BLS12-381 nhận dạng?

Một cách tiếp cận khác (có lẽ đơn giản hơn) sẽ là xây dựng một cam kết từ tất cả các khóa BLS12-381 nhận dạng của người xác nhận và thực hiện bằng chứng thành viên về cam kết đó.

Tuy nhiên, cách tiếp cận này sẽ yêu cầu người xác thực chèn khóa riêng nhận dạng của họ vào hệ thống chứng minh ZK để tạo bằng chứng thành viên hợp lệ và tính toán khóa dẫn xuất duy nhất.

Chúng tôi quyết định không áp dụng phương pháp này vì việc chèn khóa nhận dạng nhạy cảm vào giao thức mã hóa phức tạp là không tốt và điều này cũng sẽ khiến người xác thực khó giữ khóa nhận dạng chính của họ ở chế độ ngoại tuyến hơn.

Hướng nghiên cứu trong tương lai

• Chúng ta có thể tránh hoàn toàn các mạch SNARK và thực hiện chứng minh thành viên và dẫn xuất khóa theo cách đại số thuần túy không?
• Liên quan: Chúng ta có thể có bằng chứng hiệu quả về giao thức thành viên mà không cần thiết lập đáng tin cậy và không cần dựa vào các hàm băm thân thiện với SNARK không?

Sự nhìn nhận

Cảm ơn Enrico Bottazzi, Cedoor, Vivian Plasencia và Wanseob đã trợ giúp trong việc điều hướng trang web của các cơ sở mã chứng minh tư cách thành viên.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [ethresear]. Mọi bản quyền thuộc về tác giả gốc [George Kadianakis , Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố từ chối trách nhiệm pháp lý: Th
   Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.