Biên soạn nguyên văn: Nanfeng

Biên soạn nguyên văn: Nanfeng

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:Giữ cho giao thức đơn giản nhất có thể trong khi vẫn cho phép chuỗi khối thực hiện tốt những gì mà một mạng chuỗi khối hiệu quả cần phải làm.Giao thức Ethereum không hoàn hảo về mặt này, đặc biệt là vì nhiều phần của nó được thiết kế vào năm 2014-2016, khi chúng tôi hiểu nó ít hơn nhiều, nhưng chúng tôi vẫn đang tích cực cố gắng giảm thiểu hết mức có thể.

Tuy nhiên, một trong những thách thức với 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 tùy 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ụ mạnh mẽ và thông minh cho phép chúng ta suy nghĩ thấu đáo hơn về sự phức tạp là sự khác biệt giữa cái mà chúng ta gọi là sự phức tạp được đóng gói vàđộ phức tạp của hệ thống(systemic complexity)。

 

"Sự phức tạp được đóng gói" xảy ra khi một hệ thống con của một hệ thống 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 một hệ thống thậm chí không thể tách biệt rõ ràng và có những 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 sơ đồ chữ ký mật mã thường được sử dụng có thể bao gồm các đường cong elip.

Chữ ký BLS trông rất đơn giản về mặt toán học:

 

H là hàm băm, m là thông báo, k và K là khóa riêng và khóa chung. Cho đến nay, đơn giản. Tuy nhiên, sự phức tạp thực sự được ẩn giấu trong định nghĩa của hàm điện tử: các cặp đường cong elip, một trong những phần toán học khó hiểu nhất của tất cả các loại mật mã.

Bây giờ, hãy xem 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 phức tạp hơn một chút:

 

Ví dụ:

Ví dụ:

• Thực hiện đa chữ ký BLS (chữ ký kết hợp của hai khóa k1 và k2) rất đơn giản: chỉ cần σ1+σ2. Nhưng tính năng đa chữ ký của Schnorr yêu cầu hai vòng tương tác và cần đối phó với một số cuộc tấn công Hủy khóa phức tạp.

• Chữ ký Schnorr cần tạo số ngẫu nhiên, nhưng chữ ký BLS thì không.

tiêu đề phụ

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 phát sinh trong nhiều thiết kế blockchain là so sánh giữa mật mã học và kinh tế học mật mã. Điều này (như trong Rollups) thường là sự lựa chọn giữa bằng chứng hợp lệ (tức là ZK-SNARK) và bằng chứng gian lận.

ZK-SNARK là công nghệ phức tạp. Mặc dù ý tưởng cơ bản đằng sau cách thức hoạt động của ZK-SNARK có thể được giải thích rõ ràng trong một bài viết, 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 đó, đây là lý do tại sao các bằng chứng của ZK-SNARK cho EVM vẫn đang được phát triển, trong khi bằng chứng gian lận cho EVM đã ở giai đoạn thử nghiệm). Việc triển khai hiệu quả bằng chứng ZK-SNARK liên quan đến thiết kế mạch được tối ưu hóa cho mục đích đặc biệt, sử dụng 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 bản thân chúng rất đơn giản: bạn chỉ cần chạy các tính toán trực tiếp trên chuỗi nếu ai đó đưa ra thách thức. Để đạ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 độ phức tạp.

Mặc dù ZK-SNARK rất phức tạp, nhưng độ phức tạp của chúng là độ phức tạp được gói gọn. Mặt khác, độ phức tạp tương đối thấp của bằng chứng gian lận chính là độ phức tạp của hệ thống. Sau đây là ví dụ về một số phức tạp của hệ thống do bằng chứng gian lận đưa ra:

• Họ 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 nhận.

• Nếu được thực hiện với sự đồng thuận, họ sẽ yêu cầu các loại giao dịch bổ sung để chứng minh gian lận, đồng thời tính đến điều gì sẽ xảy ra nếu nhiều người tham gia cạnh tranh để gửi bằng chứng gian lận cùng một lúc.

• Họ dựa vào một mạng đồng bộ hóa.

• Chúng cho phép các cuộc tấn công kiểm duyệt cũng được sử dụng để đánh cắp.

• Rollup dựa trên 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.

tiêu đề phụ

ví dụ khác nhau

• PoW (Đồng thuận Nakamoto):Độ phức tạp đóng gói thấp hơn, bởi vì cơ chế rất đơn giản và dễ hiểu, nhưng độ phức tạp của hệ thống cao hơn (chẳng hạn như tấn công khai thác ích kỷ).

• Hàm băm:Độ phức tạp của bao bì cao, nhưng với các đặc tính rất dễ hiểu, nên độ phức tạp của hệ thống thấp.

• Thuật toán xáo trộn ngẫu nhiên:Thuật toán xáo trộn có thể phức tạp về mặt nội tại (như Whisk) nhưng đảm bảo tính ngẫu nhiên mạnh, dễ hiểu; hoặc đơn giản về mặt nội tại nhưng có thể tạo ra các tính chất ngẫu nhiên yếu và khó phân tích (như độ phức tạp của hệ thống).

• Giá trị trích xuất của người 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 ưu đãi của giao thức bằng cách đề xuất các khối theo những cách rất bất thường.

• Cây vạn tuế:tiêu đề phụ

Làm thế nào để chúng ta cân nhắc điều đó?

Thông thường, tùy chọn có độ phức tạp đóng gói thấp hơn cũng là tùy chọn có độ phức tạp hệ thống thấp hơn, do đó, có một tùy 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 sự phức tạp này và sự phức tạp khác. Tại thời điểm này, rõ ràng là nếu nó gói gọn trong sự phức tạp thì nó sẽ ít nguy hiểm hơn. Rủi ro do sự phức tạp của một hệ thống gây ra không phải là một chức năng đơn giản theo độ dài của thông số kỹ thuật; một đoạn nhỏ 10 dòng của thông số kỹ thuật tương tác với các phần khác sẽ phức tạp hơn chức năng 100 dòng nếu không được xem xét một hộp đen.

Tuy nhiên, có những hạn chế đối với phương pháp này, đó là ưu tiên gói gọn sự phức tạp. Lỗi phần mềm có thể xuất hiện trong bất kỳ đoạn mã nào, khi mã ngày càng lớn thì xác suất xảy ra lỗi gần bằng 1. Đôi khi, những gì bắt đầu như sự phức tạp của việc đóng gói có thể trở thành sự phức tạp của hệ thống khi bạn cần tương tác với các hệ thống con theo những cách mới và bất 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 này dường như được gói gọn: 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ị có thể đọc và ghi, vì vậy chúng ta không phải lo lắng về cách thức cây được xây dựng .

Tuy nhiên, sau đó, sự phức tạp này được chứng minh là có ý nghĩa 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") có kích thước có thể dự đoán được một cách đáng tin cậy. . Đ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 các quy trình lưu trữ.Tại sao sự phức tạp của bao bì trở nên có hệ thống? Vì giao diện đã thay đổi.Giải pháp là gì? Cá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ế cây đơn cấp cân bằng.

Cuối cùng, loại phức tạp nào được ưu tiên hơn trong bất kỳ tình huống cụ thể nào là một câu hỏi không dễ trả lời.Điều tốt nhất chúng tôi có thể làm là hỗ trợ độ phức tạp đóng gói ở mức vừa phải, nhưng không quá nhiều và thực hiện phán đoán của chúng tôi trong từng trường hợp cụ thể. cóĐôi khi, thực sự là cách tốt nhất để hy sinh một chút độ phức tạp của hệ thống để giảm đáng kể độ phức tạp của bao bì. Những lần khác, bạn thậm chí có thể đánh giá sai những gì được đóng gói và những gì không. Mọi tình huống đều khác nhau.