2022 ngày 28 tháng 2
Xem tất cả bài viết
Một trong những mục tiêu chính của thiết kế giao thức Ethereum là giảm thiểu độ phức tạp: làm cho giao thức trở nên đơn giản nhất có thể, trong khi vẫn tạo ra một chuỗi khối có thể làm những gì mà một chuỗi khối hiệu quả cần làm. Giao thức Ethereum còn lâu mới hoàn hảo, đặc biệt là vì phần lớn giao thức này được thiết kế vào năm 2014-2016 khi chúng tôi hiểu biết ít hơn nhiều, nhưng chúng tôi vẫn nỗ lực tích cực để giảm độ phức tạp bất cứ khi nào có thể.
Tuy nhiên, một trong những thách thức của mục tiêu này là độ phức tạp rất khó xác định và đôi khi, bạn phải đánh đổi giữa hai lựa chọn đưa ra các loại độ phức tạp khác nhau và có chi phí khác nhau. Làm thế nào để chúng ta so sánh?
Một công cụ trí tuệ mạnh mẽ cho phép suy nghĩ nhiều sắc thái hơn về sự phức tạp là phân biệt giữa cái mà chúng ta sẽ gọi là độ phức tạp được đóng gói và sự phức tạp của hệ thống.
Độ phức tạp được đóng gói xảy ra khi có một hệ thống với các hệ thống con phức tạp bên trong nhưng lại thể hiện một “giao diện” đơn giản với bên ngoài. Sự phức tạp của hệ thống xảy ra khi các phần khác nhau của hệ thống thậm chí không thể tách biệt rõ ràng và có các tương tác phức tạp với nhau.
Dưới đây là một vài ví dụ.
Chữ ký BLS so với chữ ký Schnorr
Chữ ký BLS và chữ ký Schnorr là hai loại sơ đồ chữ ký mật mã phổ biến có thể được thực hiện bằng các đường cong elip.
Chữ ký BLS xuất hiện rất đơn giản về mặt toán học:
ký tên: \(\sigma = H(m) * k\)
xác minh: \(e([1]\sigma) \stackrel{?}{=} e(H(m), K)\)
\(H\) là một hàm băm, \(m\) là tin nhắn, và \(k\) và \(K\) là khóa riêng và khóa chung. Cho đến nay, rất đơn giản. Tuy nhiên, sự phức tạp thực sự được ẩn bên trong định nghĩa của \(e\) chức năng: các cặp đường cong elip, một trong những phần toán học khó hiểu nhất trong tất cả các loại mật mã.
Bây giờ, hãy xem xét chữ ký của Schnorr. Chữ ký Schnorr chỉ dựa trên các đường cong elip cơ bản. Nhưng logic ký và xác minh có phần phức tạp hơn:
Vậy… loại chữ ký nào “đơn giản” hơn? Nó phụ thuộc vào những gì bạn quan tâm! Chữ ký BLS có độ phức tạp kỹ thuật rất lớn, nhưng tất cả sự phức tạp đó đều nằm trong định nghĩa của \(e\) hàm số. Nếu bạn đối xử với \(e\) hoạt động như một hộp đen, chữ ký BLS thực sự rất dễ dàng. Mặt khác, chữ ký Schnorr có ít toàn bộ phức tạp, nhưng chúng có nhiều mảnh ghép có thể tương tác với thế giới bên ngoài theo những cách phức tạp.
Ví dụ:
- Thực hiện đa chữ ký BLS (chữ ký kết hợp từ hai khóa \(k_1\) và \(k_2\)) thật dễ dàng: chỉ cần lấy \(\sigma_1 + \sigma_2\). Nhưng một đa chữ ký Schnorr yêu cầu hai vòng tương tác và có những cuộc tấn công hủy khóa phức tạp cần được xử lý.
- Chữ ký Schnorr yêu cầu tạo số ngẫu nhiên, chữ ký BLS thì không.
Các cặp đường cong elip nói chung là một “miếng bọt biển phức tạp” mạnh mẽ ở chỗ chúng chứa một lượng lớn độ phức tạp được đóng gói, nhưng cho phép các giải pháp có độ phức tạp hệ thống ít hơn nhiều. Điều này cũng đúng trong lĩnh vực cam kết đa thức: so sánh tính đơn giản của cam kết KZG (yêu cầu ghép nối) với logic bên trong phức tạp hơn nhiều của các đối số tích bên trong (không yêu cầu).
Mật mã học so với kinh tế học tiền điện tử
Một lựa chọn thiết kế quan trọng xuất hiện trong nhiều thiết kế chuỗi khối là mật mã học so với kinh tế học mật mã. Thông thường (ví dụ: trong tổng số) điều này xuất hiện dưới dạng lựa chọn giữa bằng chứng hợp lệ (hay còn gọi là ZK-SNARK) và bằng chứng gian lận.
ZK-SNARK là công nghệ phức tạp. Mặc dù các ý tưởng cơ bản đằng sau cách thức hoạt động của chúng có thể được giải thích trong một bài đăng, nhưng thực tế việc triển khai ZK-SNARK để xác minh một số phép tính phức tạp hơn nhiều lần so với bản thân phép tính (do đó tại sao ZK-SNARK cho EVM vẫn đang được phát triển trong khi gian lận bằng chứng cho EVM đã ở giai đoạn thử nghiệm). Triển khai ZK-SNARK một cách hiệu quả liên quan đến thiết kế mạch với mục đích tối ưu hóa đặc biệt, làm việc với các ngôn ngữ lập trình không quen thuộc và nhiều thách thức khác. Mặt khác, bằng chứng gian lận vốn đã đơn giản: nếu ai đó đưa ra thách thức, bạn chỉ cần trực tiếp chạy tính toán trên chuỗi. Để đạt hiệu quả, đôi khi một sơ đồ tìm kiếm nhị phân được thêm vào, nhưng ngay cả điều đó cũng không làm tăng thêm quá nhiều phức tạp.
Nhưng trong khi ZK-SNARK rất phức tạp, thì độ phức tạp của chúng là độ phức tạp được đóng gói. Mặt khác, độ phức tạp tương đối nhẹ của bằng chứng gian lận là có hệ thống. Dưới đây là một số ví dụ về sự phức tạp của hệ thống mà bằng chứng gian lận giới thiệu:
- Chúng yêu cầu kỹ thuật khuyến khích cẩn thận để tránh tình trạng tiến thoái lưỡng nan của người xác minh.
- Nếu được thực hiện đồng thuận, họ yêu cầu các loại giao dịch bổ sung cho bằng chứng gian lận, cùng với lý do về điều gì sẽ xảy ra nếu nhiều tác nhân cạnh tranh để gửi bằng chứng gian lận cùng một lúc.
- Chúng phụ thuộc vào một mạng đồng bộ.
- Chúng cho phép các cuộc tấn công kiểm duyệt cũng được sử dụng để thực hiện hành vi trộm cắp.
- Rollup dựa trên bằng chứng gian lận yêu cầu các nhà cung cấp thanh khoản hỗ trợ rút tiền ngay lập tức.
Vì những lý do này, ngay cả từ góc độ phức tạp, các giải pháp mã hóa thuần túy dựa trên ZK-SNARK có thể sẽ an toàn hơn về lâu dài: ZK-SNARK có các bộ phận phức tạp hơn một số mọi người phải suy nghĩ về, nhưng họ có ít cảnh báo nguy hiểm hơn tất cả mọi người phải suy nghĩ về.
ví dụ khác
- Bằng chứng công việc (đồng thuận Nakamoto) – độ phức tạp đóng gói thấp, vì cơ chế cực kỳ đơn giản và dễ hiểu, nhưng độ phức tạp hệ thống cao hơn (ví dụ: các cuộc tấn công khai thác ích kỷ).
- hàm băm – độ phức tạp đóng gói cao, nhưng thuộc tính rất dễ hiểu nên độ phức tạp hệ thống thấp.
- Thuật toán xáo trộn ngẫu nhiên – các thuật toán xáo trộn có thể phức tạp bên trong (như trong Whisk) nhưng dẫn đến các đảm bảo dễ hiểu về tính ngẫu nhiên mạnh, hoặc đơn giản hơn bên trong nhưng dẫn đến các thuộc tính ngẫu nhiên yếu hơn và khó phân tích hơn (độ phức tạp hệ thống).
- Giá trị khai thác có thể khai thác (MEV) – một giao thức đủ mạnh để hỗ trợ các giao dịch phức tạp có thể khá đơn giản trong nội bộ, nhưng những giao dịch phức tạp đó có thể có tác động hệ thống phức tạp đối với các khuyến khích của giao thức bằng cách góp phần khuyến khích đề xuất các khối theo những cách rất bất thường.
- Mặc quần áo – Các cây Verkle có một số độ phức tạp được đóng gói, trên thực tế là nhiều hơn một chút so với các cây băm Merkle đơn giản. Tuy nhiên, về mặt hệ thống, các cây Verkle trình bày chính xác giao diện tương đối rõ ràng và đơn giản của bản đồ khóa-giá trị. Sự phức tạp chính của hệ thống “rò rỉ” là khả năng kẻ tấn công thao túng cây để làm cho một giá trị cụ thể có một nhánh rất dài; nhưng rủi ro này là như nhau đối với cả cây Verkle và cây Merkle.
Làm thế nào để chúng ta thực hiện sự đánh đổi?
Thông thường, lựa chọn ít phức tạp hơn cũng là lựa chọn ít phức tạp hệ thống hơn, và do đó, có một lựa chọn rõ ràng là đơn giản hơn. Nhưng vào những thời điểm khác, bạn phải đưa ra lựa chọn khó khăn giữa loại phức tạp này và loại phức tạp khác. Điều cần làm rõ vào thời điểm này là sự phức tạp sẽ ít nguy hiểm hơn nếu nó được đóng gói. Rủi ro từ sự phức tạp của một hệ thống không phải là một chức năng đơn giản về thời lượng của đặc tả; một phần nhỏ 10 dòng của thông số kỹ thuật tương tác với mọi phần khác sẽ làm tăng thêm độ phức tạp so với hàm 100 dòng được coi là hộp đen.
Tuy nhiên, có những giới hạn đối với cách tiếp cận ưa thích sự phức tạp được đóng gói này. Lỗi phần mềm có thể xảy ra trong bất kỳ đoạn mã nào và khi nó càng lớn thì xác suất xảy ra lỗi càng gần bằng 1. Đôi khi, khi bạn cần tương tác với một hệ thống phụ theo một cách mới và không mong đợi, sự phức tạp ban đầu được gói gọn có thể trở thành hệ thống.
Một ví dụ về cái sau là cây trạng thái hai cấp hiện tại của Ethereum, có cây đối tượng tài khoản, trong đó mỗi đối tượng tài khoản lại có cây lưu trữ riêng.
Cấu trúc cây này rất phức tạp, nhưng lúc đầu, sự phức tạp dường như được gói gọn trong đó: phần còn lại của giao thức tương tác với cây như một kho lưu trữ khóa/giá trị mà bạn có thể đọc và ghi vào đó, vì vậy chúng tôi không phải lo lắng về cách cây được cấu trúc.
Tuy nhiên, sau đó, sự phức tạp hóa ra lại có tác động mang tính hệ thống: khả năng các tài khoản có các cây lưu trữ lớn tùy ý có nghĩa là không có cách nào để mong đợi một phần trạng thái cụ thể (ví dụ: “tất cả các tài khoản bắt đầu bằng 0x1234”) một cách đáng tin cậy. có kích thước dự đoán được. Điều này làm cho việc chia trạng thái thành nhiều phần trở nên khó khăn hơn, làm phức tạp việc thiết kế các giao thức đồng bộ hóa và cố gắng phân phối quy trình lưu trữ. Tại sao sự phức tạp được đóng gói lại trở thành hệ thống? Do giao diện thay đổi. Cách khắc phục? Đề xuất hiện tại để chuyển sang cây Verkle cũng bao gồm việc chuyển sang thiết kế một lớp cân bằng tốt cho cây,
Cuối cùng, loại phức tạp nào được ưu tiên trong bất kỳ tình huống cụ thể nào là một câu hỏi không có câu trả lời dễ dàng. Điều tốt nhất mà chúng ta có thể làm là có thái độ ủng hộ vừa phải sự phức tạp được đóng gói, nhưng không quá nhiều, và thực hiện phán đoán của chúng ta trong từng trường hợp cụ thể. Đôi khi, hy sinh một chút độ phức tạp của hệ thống để cho phép giảm đáng kể độ phức tạp được đóng gói thực sự là điều tốt nhất nên làm. Và những lần khác, bạn thậm chí có thể đánh giá sai những gì được gói gọn và những gì không. Mỗi tình huống là khác nhau.
