Giao thức Ethereum có nên gói gọn nhiều chức năng hơn không?

Bài viết này được thực hiện mới đây bởi Vitalik Buterin.

Ngay từ khi bắt đầu dự án Ethereum, đã có một triết lý mạnh mẽ là cố gắng làm cho Ethereum cốt lõi trở nên đơn giản nhất có thể và đạt được điều này nhiều nhất có thể bằng cách xây dựng các giao thức trên đó. Trong không gian blockchain, cuộc tranh luận “xây dựng trên L1” và “tập trung vào L2” thường được coi chủ yếu là về quy mô, nhưng trên thực tế, có những vấn đề tương tự trong việc đáp ứng nhu cầu của nhiều người dùng Ethereum: Trao đổi tài sản kỹ thuật số, quyền riêng tư , tên người dùng, mã hóa nâng cao, bảo mật tài khoản, khả năng chống kiểm duyệt, bảo vệ chạy trước, v.v. Tuy nhiên, gần đây đã có một số nỗ lực thận trọng nhằm đưa nhiều tính năng này vào giao thức Ethereum cốt lõi.

Bài viết này sẽ đi sâu vào một số lý luận triết học đằng sau triết lý ban đầu về sự đóng gói tối thiểu, cũng như một số cách suy nghĩ gần đây về những ý tưởng này. Mục tiêu sẽ là bắt đầu xây dựng một khuôn khổ để xác định rõ hơn các mục tiêu khả thi trong đó việc đóng gói một số chức năng nhất định có thể đáng xem xét.

Một triết lý ban đầu về giao thức tối giản

Trong lịch sử ban đầu của cái mà lúc đó được gọi là “Ethereum 2.0”, có một mong muốn mạnh mẽ là tạo ra một giao thức rõ ràng, đơn giản và đẹp mắt, cố gắng xây dựng chính nó ít nhất có thể và để lại hầu hết mọi công việc như vậy cho người dùng. Lý tưởng nhất là giao thức chỉ là một máy ảo và việc xác thực một khối chỉ là một lệnh gọi máy ảo.

“Chức năng chuyển trạng thái” (chức năng xử lý khối) sẽ chỉ là một lệnh gọi VM và tất cả logic khác sẽ diễn ra thông qua các hợp đồng: một số hợp đồng cấp hệ thống, nhưng chủ yếu là hợp đồng do người dùng cung cấp. Một tính năng rất hay của mô hình này là thậm chí toàn bộ một hard fork có thể được mô tả như một giao dịch duy nhất cho hợp đồng xử lý khối, giao dịch này sẽ được quản trị ngoài chuỗi hoặc trên chuỗi phê duyệt và sau đó nâng cấp quyền để chạy.

Những cuộc thảo luận này trong năm 2015 áp dụng cụ thể cho hai lĩnh vực mà chúng tôi xem xét: trừu tượng hóa tài khoản và mở rộng quy mô . Trong trường hợp chia tỷ lệ, ý tưởng là cố gắng tạo ra một dạng chia tỷ lệ trừu tượng tối đa giống như một phần mở rộng tự nhiên của sơ đồ trên. Các hợp đồng có thể gọi dữ liệu không được lưu trữ bởi hầu hết các nút Ethereum và giao thức sẽ phát hiện điều này và giải quyết cuộc gọi thông qua một số chức năng tính toán mở rộng rất chung. Từ góc nhìn của máy ảo, cuộc gọi sẽ đi vào một hệ thống con riêng biệt nào đó và sau đó sẽ trả lại câu trả lời đúng một cách thần kỳ sau đó một thời gian.

Chúng tôi đã khám phá ngắn gọn ý tưởng này nhưng nhanh chóng từ bỏ nó vì chúng tôi quá tập trung vào việc chứng minh rằng bất kỳ loại quy mô blockchain nào cũng có thể thực hiện được. Mặc dù như chúng ta sẽ thấy sau, sự kết hợp giữa lấy mẫu tính khả dụng của dữ liệu và ZK-EVM có nghĩa là một tương lai khả dĩ cho việc mở rộng quy mô Ethereum thực sự rất gần với tầm nhìn này! Mặt khác, với việc trừu tượng hóa tài khoản, ngay từ đầu chúng tôi đã biết rằng một số hình thức triển khai có thể thực hiện được, vì vậy, nghiên cứu ngay lập tức bắt đầu cố gắng thực hiện điều gì đó gần nhất có thể với điểm xuất phát thuần túy là “giao dịch chỉ là một cuộc gọi”.

Một trong những đoạn mã chính ở đây là valid_transaction(state, tx), chịu trách nhiệm kiểm tra xem nonce và chữ ký của giao dịch có chính xác hay không. Mục tiêu thực sự của việc trừu tượng hóa tài khoản ngay từ đầu là cho phép người dùng thay thế xác minh không gia tăng cơ bản và xác minh ECDSA bằng logic xác minh của riêng họ, để người dùng có thể dễ dàng sử dụng các tính năng như khôi phục xã hội và ví đa chữ ký. Vì vậy, việc tìm cách cơ cấu lại apply_transaction thành một lệnh gọi EVM đơn giản không chỉ là nhiệm vụ “làm sạch mã vì mục đích làm cho mã sạch”; mà đúng hơn, đó là việc chuyển logic vào mã tài khoản của người dùng, mang lại cho người dùng sự linh hoạt mà họ cần.

Tuy nhiên, việc nhấn mạnh rằng apply_transaction chứa càng ít logic cố định càng tốt sẽ tạo ra rất nhiều thách thức. Chúng ta có thể xem xét một trong những đề xuất trừu tượng hóa tài khoản sớm nhất, EIP-86.

Nếu EIP-86 được đưa vào nguyên trạng, nó sẽ làm giảm độ phức tạp của EVM với cái giá phải trả là làm tăng đáng kể độ phức tạp của các phần khác trong ngăn xếp Ethereum, về cơ bản đòi hỏi cùng một mã phải được viết ở nơi khác, ngoài việc giới thiệu toàn bộ lớp kỳ lạ mới. Ví dụ, cùng một giao dịch có cùng giá trị băm có thể xuất hiện nhiều lần trong chuỗi, chưa kể đến vấn đề vô hiệu hóa nhiều lần.

Kể từ đó, việc trừu tượng hóa tài khoản đã phát triển theo từng giai đoạn. EIP-86 sau này trở thành EIP-208 và cuối cùng là EIP-2938 thực tế.

Tuy nhiên, EIP-2938 không hề tối giản. Nội dung của nó bao gồm:

• Loại giao dịch mới
•  Ba biến toàn cục phạm vi giao dịch mới
• Hai mã opcode mới, bao gồm mã opcode PAYgas rất phức tạp để xử lý việc kiểm tra giá gas và giới hạn gas, làm điểm dừng thực thi EVM và để lưu trữ tạm thời ETH để thanh toán phí một lần
• Một tập hợp các chiến lược khai thác và phát sóng lại phức tạp, bao gồm danh sách các opcode bị cấm trong giai đoạn xác minh giao dịch

Trong nỗ lực đạt được sự trừu tượng hóa tài khoản mà không cần sự tham gia của các nhà phát triển cốt lõi Ethereum (những người tập trung vào việc tối ưu hóa ứng dụng khách Ethereum và triển khai việc hợp nhất), EIP-2938 cuối cùng đã được cấu trúc lại thành ERC-4337, hoàn toàn không có giao thức.

Bởi vì đây là ERC nên nó không yêu cầu hard fork và về mặt kỹ thuật tồn tại “bên ngoài giao thức Ethereum”. Vậy…vấn đề đã được giải quyết? Hóa ra không phải vậy. Lộ trình trung hạn hiện tại cho ERC-4337 thực sự liên quan đến việc chuyển đổi phần lớn ERC-4337 thành một loạt các tính năng giao thức, đây là một ví dụ hữu ích về hướng dẫn tại sao nên xem xét đường dẫn này.

Gói ERC-4337 

Có một số lý do chính được thảo luận để cuối cùng đưa ERC-4337 trở lại giao thức:

• Hiệu suất sử dụng gas : Bất kỳ hoạt động nào được thực hiện bên trong EVM đều phát sinh một số chi phí sử dụng máy ảo, bao gồm cả sự thiếu hiệu quả khi sử dụng các tính năng tốn nhiều gas như khe lưu trữ. Hiện tại, những sự thiếu hiệu quả bổ sung này cộng lại ít nhất là 20.000 gas, nếu không muốn nói là nhiều hơn. Đưa các thành phần này vào giao thức là cách dễ nhất để loại bỏ những vấn đề này.
• Rủi ro lỗi mã : Nếu “hợp đồng điểm đầu vào” ERC-4337 có một lỗi đủ nghiêm trọng, tất cả các ví tương thích với ERC-4337 có thể thấy toàn bộ số tiền của họ cạn kiệt. Việc thay thế hợp đồng bằng chức năng trong giao thức tạo ra nghĩa vụ ngầm phải sửa lỗi mã thông qua hard fork, từ đó loại bỏ nguy cơ người dùng hết tiền.
• Hỗ trợ các mã opcode EVM như txt.origin. Bản thân ERC-4337 khiến txt.origin trả về địa chỉ của một “bộ đóng gói” đóng gói một tập hợp hành động của người dùng vào một giao dịch. Việc trừu tượng hóa tài khoản gốc giải quyết vấn đề này bằng cách làm cho txt.origin trỏ đến tài khoản thực gửi giao dịch, làm cho nó hoạt động giống như EOA.
• Khả năng chống kiểm duyệt : Một trong những thách thức đối với việc tách biệt người đề xuất/người xây dựng là việc xem xét các giao dịch riêng lẻ trở nên dễ dàng hơn. Trong một thế giới mà giao thức Ethereum có thể xác định các giao dịch riêng lẻ, vấn đề này có thể được giảm bớt đáng kể nhờ danh sách bao gồm, cho phép người đề xuất chỉ định danh sách các giao dịch phải được đưa vào hai vị trí tiếp theo trong hầu hết các trường hợp. Tuy nhiên, ERC-4337 bên ngoài giao thức gói gọn “hoạt động của người dùng” trong một giao dịch duy nhất, khiến hoạt động của người dùng không rõ ràng đối với giao thức Ethereum; do đó, danh sách bao gồm do giao thức Ethereum cung cấp sẽ không thể cung cấp khả năng chống kiểm duyệt cho người dùng ERC-4337 hoạt động. Việc gói ERC-4337 và biến hành động của người dùng thành loại giao dịch “phù hợp” sẽ giải quyết được vấn đề này.

Điều đáng nói là ở dạng hiện tại, ERC-4337 đắt hơn đáng kể so với các giao dịch Ethereum “cơ bản”: một giao dịch tốn 21.000 gas, trong khi ERC-4337 tốn khoảng 42.000 gas.

Về lý thuyết, có thể điều chỉnh hệ thống chi phí gas EVM cho đến khi chi phí trong giao thức và chi phí truy cập vào bộ lưu trữ ngoài giao thức khớp nhau; không có lý do gì phải tốn 9000 gas để chuyển ETH khi các loại lưu trữ khác chỉnh sửa hoạt động rẻ hơn. Trên thực tế, hai EIP liên quan đến quá trình chuyển đổi cây Verkle sắp tới thực sự đang cố gắng thực hiện điều đó. Nhưng ngay cả khi chúng tôi làm điều đó, thì có một lý do rõ ràng tại sao dù EVM có hiệu quả đến đâu thì các chức năng giao thức được đóng gói chắc chắn sẽ rẻ hơn nhiều so với mã EVM: mã được đóng gói không cần phải trả phí gas cho việc tải trước.

Ví ERC-4337 đầy đủ chức năng có kích thước lớn, với việc triển khai này được biên dịch và đưa vào chuỗi chiếm khoảng 12.800 byte. Tất nhiên, bạn có thể triển khai mã này một lần và sử dụng DELEGATECALL để cho phép từng ví riêng lẻ gọi nó, nhưng bạn vẫn cần truy cập mã trong mọi khối nơi nó được sử dụng. Theo Verkle tree gas cost EIP, 12.800 byte sẽ tạo thành các khối 413. Việc truy cập các khối này sẽ yêu cầu trả gấp 2 lần chi phí nhân chứng (tổng cộng 3.800 gas) và gấp 413 lần chi phí nhân chứng chunk_cost (tổng cộng 82.600 gas). . Điều đó thậm chí còn chưa đề cập đến chính điểm vào ERC-4337, trong phiên bản 0.6.0 có 23.689 byte trên chuỗi (khoảng 158.700 gas để tải theo quy tắc EIP của Verkle tree).

Điều này dẫn đến một vấn đề: chi phí gas khi thực sự truy cập các mã này phải được phân bổ theo một cách nào đó qua các giao dịch. Cách tiếp cận hiện tại được ERC-4337 sử dụng không tốt lắm: giao dịch đầu tiên trong gói tiêu tốn chi phí lưu trữ/đọc mã một lần, khiến giao dịch này đắt hơn nhiều so với các giao dịch khác. Việc đóng gói nội giao thức sẽ cho phép các thư viện dùng chung công cộng này trở thành một phần của giao thức và mọi người đều có thể truy cập miễn phí.

Chúng ta có thể học được gì từ ví dụ này và khi nào nên thực hành đóng gói một cách tổng quát hơn?

Trong ví dụ này, chúng ta thấy một số lý do cơ bản khác nhau để đóng gói các phần trừu tượng hóa tài khoản trong các giao thức.

• Các phương pháp tiếp cận dựa trên thị trường “đẩy sự phức tạp đến mức tối đa” có nhiều khả năng thất bại nhất khi chi phí cố định cao. Trên thực tế, lộ trình trừu tượng hóa tài khoản dài hạn dường như có rất nhiều chi phí cố định cho mỗi khối. 244.100 gas để tải mã ví tiêu chuẩn là một chuyện; nhưng việc tổng hợp có thể bổ sung thêm hàng trăm nghìn gas cho việc xác minh ZK-SNARK, cũng như chi phí xác minh bằng chứng trên chuỗi. Không có cách nào để tính phí những chi phí này cho người dùng mà không gây ra sự kém hiệu quả trên diện rộng của thị trường và việc biến một số tính năng này thành các tính năng giao thức mà mọi người có thể truy cập miễn phí sẽ giải quyết rất tốt vấn đề này.
• Phản hồi của toàn cộng đồng đối với lỗi mã. Nếu một đoạn mã nào đó được sử dụng bởi tất cả người dùng hoặc một phạm vi người dùng rất rộng, thì việc cộng đồng blockchain đảm nhận trách nhiệm thực hiện một hard fork để sửa bất kỳ lỗi nào phát sinh sẽ có ý nghĩa hơn. ERC-4337 giới thiệu một lượng lớn mã được chia sẻ trên toàn cầu và về lâu dài, chắc chắn việc sửa lỗi trong mã thông qua hard fork sẽ hợp lý hơn là khiến người dùng mất một lượng lớn ETH.
• Đôi khi, một dạng giao thức mạnh hơn có thể được triển khai bằng cách tận dụng trực tiếp chức năng của nó. Ví dụ chính ở đây là các tính năng chống kiểm duyệt trong giao thức, chẳng hạn như danh sách bao gồm: Danh sách bao gồm trong giao thức có thể đảm bảo khả năng chống kiểm duyệt tốt hơn các phương pháp ngoài giao thức. bao gồm danh sách, người dùng cá nhân Hoạt động ở cấp độ yêu cầu giao thức phải “rõ ràng”. Một ví dụ khác ít được biết đến hơn là thiết kế bằng chứng cổ phần Ethereum thời kỳ 2017 có tính năng trừu tượng hóa tài khoản của các khóa cổ phần, đã bị loại bỏ để chuyển sang BLS được đóng gói vì BLS hỗ trợ cơ chế “tổng hợp” phải được triển khai tại giao thức và cấp độ mạng, điều này có thể làm cho việc xử lý số lượng lớn chữ ký hiệu quả hơn.

Nhưng điều quan trọng cần nhớ là ngay cả việc đóng gói các phần trừu tượng hóa tài khoản trong các giao thức vẫn là một sự “giải nén” rất lớn so với hiện trạng . Ngày nay, các giao dịch Ethereum cấp cao nhất chỉ có thể được bắt đầu từ các tài khoản thuộc sở hữu bên ngoài (EOA), được xác minh bằng chữ ký đường cong elip 256k 1 giây duy nhất. Việc trừu tượng hóa tài khoản sẽ loại bỏ điều này và để lại các điều kiện xác thực cho người dùng xác định. Do đó, trong câu chuyện về việc trừu tượng hóa tài khoản này, chúng ta cũng thấy lý do lớn nhất chống lại việc đóng gói: tính linh hoạt trong việc đáp ứng nhu cầu của những người dùng khác nhau .

Chúng ta hãy làm rõ hơn câu chuyện bằng cách xem xét một số ví dụ khác về các tính năng gần đây đã được xem xét để đóng gói. Chúng tôi sẽ đặc biệt chú ý đến: ZK-EVM, sự phân tách giữa người đề xuất và người xây dựng, nhóm bộ nhớ riêng, đặt cược thanh khoản và quá trình biên dịch trước mới .

Gói thầu ZK-EVM

Hãy chuyển sự chú ý của chúng ta sang một mục tiêu đóng gói tiềm năng khác cho giao thức Ethereum: ZK-EVM. Hiện tại, chúng tôi có một số lượng lớn ZK-rollup, tất cả đều phải viết mã khá giống nhau để xác minh việc thực thi các khối Ethereum tương tự trong ZK-SNARK. Có một hệ sinh thái triển khai độc lập khá đa dạng: PSE ZK-EVM, Kakarot , Polygon ZK-EVM, Linea , Zeth và các hệ sinh thái khác.

Một cuộc tranh cãi gần đây trong thế giới EVM ZK-rollup liên quan đến cách xử lý các lỗi có thể phát sinh trong mã ZK. Hiện tại, tất cả các hệ thống đang hoạt động này đều có một số dạng cơ chế “hội đồng bảo mật” để kiểm soát hệ thống chứng thực trong trường hợp có lỗi. Năm ngoái, tôi đã cố gắng tạo ra một khuôn khổ tiêu chuẩn hóa nhằm khuyến khích các dự án làm rõ mức độ họ tin tưởng vào hệ thống chứng thực cũng như mức độ tin cậy của họ đối với Hội đồng Bảo an, đồng thời giảm dần quyền lực của họ đối với tổ chức đó theo thời gian.

Tuy nhiên, có cảm giác rằng một số công việc này có vẻ dư thừa. Chúng tôi đã có lớp cơ sở Ethereum, nó có EVM và chúng tôi đã có cơ chế hoạt động để xử lý các lỗi trong quá trình triển khai: nếu có lỗi, máy khách sẽ được cập nhật để sửa lỗi đó và chuỗi sẽ tiếp tục hoạt động . Từ quan điểm của khách hàng có lỗi, có vẻ như các khối đã được hoàn thiện sẽ không còn được xác nhận nữa, nhưng ít nhất chúng tôi sẽ không thấy người dùng bị mất tiền. Tương tự như vậy, nếu các bản tổng hợp chỉ muốn duy trì vai trò tương đương của EVM thì họ cần triển khai quản trị của riêng mình để liên tục thay đổi các quy tắc ZK-EVM nội bộ của mình để phù hợp với các bản nâng cấp lên lớp cơ sở Ethereum, điều này có vẻ sai vì cuối cùng chúng được xây dựng trên đầu trang. của chính lớp cơ sở Ethereum, nó biết khi nào nên nâng cấp và tuân theo những quy tắc mới nào.

Vì các L2 ZK-EVM này về cơ bản sử dụng EVM giống hệt như Ethereum, nên bằng cách nào đó chúng ta có thể kết hợp “xác minh việc thực thi EVM trong ZK” vào chức năng giao thức và xử lý các trường hợp ngoại lệ bằng cách áp dụng sự đồng thuận xã hội của Ethereum, như lỗi và nâng cấp, giống như chúng ta đã làm đối với bản thân việc thực thi EVM của lớp cơ sở?

Đây là một chủ đề quan trọng và đầy thách thức.

Một chủ đề tranh luận có thể xảy ra liên quan đến tính sẵn có của dữ liệu trong ZK-EVM nguyên gốc là tính trạng thái. ZK-EVM sẽ sử dụng dữ liệu hiệu quả hơn nhiều nếu chúng không cần mang theo dữ liệu “nhân chứng”. Nghĩa là, nếu một phần dữ liệu cụ thể đã được đọc hoặc ghi trong một số khối trước đó, chúng ta có thể đơn giản giả định rằng người chứng minh có quyền truy cập vào nó và không cần phải cung cấp lại nó. Vấn đề không chỉ là không tải lại bộ nhớ và mã; hóa ra là nếu một bản tổng hợp nén dữ liệu một cách chính xác thì nén có trạng thái có thể tiết kiệm dữ liệu gấp 3 lần so với nén không trạng thái.

Điều này có nghĩa là đối với quá trình biên dịch trước ZK-EVM, chúng tôi có hai tùy chọn:

1. Quá trình biên dịch trước yêu cầu tất cả dữ liệu phải có sẵn trong cùng một khối . Điều này có nghĩa là bộ chứng minh có thể không có trạng thái, nhưng cũng có nghĩa là việc sử dụng ZK-rollup được biên dịch trước này đắt hơn nhiều so với việc sử dụng mã tùy chỉnh để tổng hợp.

2. Biên dịch trước cho phép con trỏ trỏ đến dữ liệu được sử dụng hoặc tạo ra bởi các lần thực thi trước đó . Điều này làm cho ZK-rollup gần đạt mức tối ưu, nhưng nó phức tạp hơn và đưa ra một trạng thái mới mà bộ chuẩn phải lưu trữ.

Những gì chúng ta có thể học hỏi từ này? Có một lý do chính đáng để gói gọn xác minh ZK-EVM theo một cách nào đó: rollup đã xây dựng phiên bản tùy chỉnh của riêng mình và Ethereum sẵn sàng triển khai EVM trên L1 với sức nặng của nhiều hoạt động triển khai và sự đồng thuận xã hội ngoài chuỗi. , điều này mang lại cảm giác như vậy sai, nhưng L2 làm công việc tương tự sẽ phải triển khai một tiện ích phức tạp liên quan đến Hội đồng Bảo an. Nhưng mặt khác, có một điểm đáng chú ý ở chi tiết: Có nhiều phiên bản ZK-EVM khác nhau, với chi phí và lợi ích khác nhau. Sự khác biệt giữa trạng thái và không trạng thái chỉ là bề nổi; những nỗ lực hỗ trợ mã tùy chỉnh “gần như EVM” đã được các hệ thống khác chứng minh có thể mang lại không gian thiết kế lớn hơn. Do đó, việc đóng gói ZK-EVM mang lại cả hứa hẹn và thách thức .

Sự tách biệt giữa người đề xuất đóng gói và người xây dựng (ePBS)

Sự gia tăng của MEV khiến việc sản xuất khối trở thành một hoạt động kinh tế trên quy mô lớn, với các tác nhân tinh vi có thể tạo ra các khối tạo ra nhiều doanh thu hơn thuật toán mặc định, thuật toán này chỉ đơn giản quan sát một nhóm giao dịch và chứa chúng. Cho đến nay, cộng đồng Ethereum đã cố gắng  giải quyết vấn đề này bằng cách sử dụng các sơ đồ phân tách người đề xuất-người xây dựng ngoài giao thức như MEV- Boost

Tuy nhiên, MEV-Boost đưa ra các giả định về độ tin cậy trong một nhóm tác nhân mới được gọi là rơle. Trong hai năm qua, đã có nhiều đề xuất tạo ra một “PBS trọn gói”. Lợi ích của việc này là gì? Trong trường hợp này, câu trả lời rất đơn giản: một PBS được xây dựng bằng cách sử dụng trực tiếp các tính năng của giao thức sẽ mạnh hơn (theo nghĩa là có các giả định về độ tin cậy yếu hơn) so với một PBS được xây dựng mà không sử dụng chúng. Điều này tương tự như trường hợp gói gọn các dự đoán về giá trong một giao thức – mặc dù trong trường hợp này có những phản đối mạnh mẽ.

Đóng gói nhóm bộ nhớ riêng

Khi người dùng gửi một giao dịch, nó sẽ ngay lập tức được công khai và hiển thị cho mọi người, ngay cả trước khi nó được đưa vào chuỗi. Điều này khiến người dùng nhiều ứng dụng dễ bị tấn công về mặt kinh tế, chẳng hạn như ứng dụng chạy trước.

Gần đây, đã có một số dự án dành riêng cho việc tạo ra các “mempool riêng tư” (hoặc “mempool tiền điện tử”), mã hóa các giao dịch của người dùng cho đến khi chúng được chấp nhận vào một khối và không thể đảo ngược.

Tuy nhiên, vấn đề là sơ đồ như vậy yêu cầu một loại mã hóa đặc biệt: Để ngăn chặn người dùng tràn ngập hệ thống và giải mã nó trước tiên, mã hóa phải được giải mã tự động sau khi giao dịch thực sự được chấp nhận và không thể đảo ngược.

Có nhiều kỹ thuật khác nhau với sự đánh đổi khác nhau để thực hiện hình thức mã hóa này. Jon Charbonneau đã từng mô tả nó rất hay:

• Mã hóa các toán tử tập trung như  Flashbots Protect .
• Mã hóa khóa thời gian , hình thức mã hóa này có thể được giải mã bởi bất kỳ ai sau các bước tính toán tuần tự nhất định và không thể song song hóa;
• Mã hóa ngưỡng tin cậy vào một ủy ban đa số trung thực để giải mã dữ liệu. Xem khái niệm về chuỗi đèn hiệu khép kín để có gợi ý cụ thể.
• Phần cứng đáng tin cậy như SGX.

Thật không may, mọi phương pháp mã hóa đều có những điểm yếu khác nhau. Mặc dù đối với mỗi giải pháp đều có một bộ phận người dùng sẵn sàng tin tưởng vào nó, nhưng không có giải pháp nào đủ tin cậy để Lớp 1 thực sự chấp nhận giải pháp đó. Vì vậy, ít nhất cho đến khi quá trình mã hóa bị trì hoãn được hoàn thiện hoặc một số đột phá công nghệ khác, việc đóng gói chức năng chống giao dịch trước trong Lớp 1 dường như là một đề xuất khó khăn , ngay cả khi đó là một tính năng đủ giá trị mà nhiều giải pháp ứng dụng đã xuất hiện.

Đặt cược thanh khoản đóng gói

Nhu cầu chung của người dùng Ethereum DeFi là khả năng sử dụng đồng thời ETH của họ để đặt cược và làm tài sản thế chấp trong các ứng dụng khác. Một yêu cầu phổ biến khác chỉ đơn giản là để thuận tiện: người dùng muốn có thể đặt cược (và bảo vệ các khóa đặt cược trực tuyến) mà không cần phải chạy một nút phức tạp và giữ nó luôn trực tuyến.

Cho đến nay, “giao diện” đặt cược đơn giản nhất đáp ứng cả hai nhu cầu này chỉ là mã thông báo ERC 20: chuyển đổi ETH của bạn thành “đặt cược ETH”, giữ nó và sau đó chuyển đổi lại. Trên thực tế,  các nhà cung cấp đặt cược thanh khoản như Lido  và  Rocket   Pool đã thực hiện việc này. Tuy nhiên, có một số cơ chế tập trung tự nhiên liên quan đến đặt cược thanh khoản: mọi người sẽ tự nhiên tham gia đặt cược phiên bản lớn nhất của ETH vì đây là phiên bản quen thuộc và thanh khoản nhất.

Mỗi phiên bản ETH đặt cược cần có một số cơ chế để xác định ai có thể trở thành người điều hành nút cơ bản. Nó không thể không giới hạn vì khi đó những kẻ tấn công sẽ tham gia và sử dụng tiền của người dùng để mở rộng các cuộc tấn công của chúng. Hiện tại, hai công ty hàng đầu là Lido  , có các nhà khai thác nút được đưa vào danh sách cho phép của DAO và Rocket Pool , cho phép bất kỳ ai chạy một nút với khoản tiền gửi là 8 ETH. Hai phương pháp có những rủi ro khác nhau: phương pháp Rocket Pool cho phép kẻ tấn công thực hiện cuộc tấn công 51% trên mạng và buộc người dùng phải trả phần lớn chi phí; đối với phương thức DAO, nếu một mã thông báo đặt cược nào đó chiếm ưu thế, nó sẽ dẫn đến một tiện ích quản trị có khả năng bị xâm phạm sẽ kiểm soát phần lớn tất cả các trình xác thực Ethereum. Theo ghi nhận của mình, các giao thức như Lido đã có sẵn các biện pháp bảo vệ, nhưng một lớp bảo vệ có thể là không đủ.

Trong ngắn hạn, một lựa chọn là khuyến khích những người tham gia hệ sinh thái sử dụng một loạt các nhà cung cấp dịch vụ đặt cược thanh khoản đa dạng để giảm khả năng người chơi thống trị gây ra rủi ro hệ thống. Tuy nhiên, về lâu dài, đây là một sự cân bằng không ổn định và việc phụ thuộc quá nhiều vào áp lực đạo đức để giải quyết vấn đề là rất nguy hiểm. Một câu hỏi tự nhiên được đặt ra: Liệu việc gói gọn một số chức năng trong giao thức để làm cho việc đặt cược thanh khoản bớt tập trung hơn có hợp lý không?

Câu hỏi quan trọng ở đây là: loại chức năng nào trong giao thức? Một vấn đề khi chỉ tạo một mã thông báo “đặt cược ETH” có thể thay thế trong giao thức là nó sẽ phải có cơ chế quản trị trên toàn Ethereum được đóng gói để chọn ai sẽ chạy các nút hoặc có kết thúc mở, nhưng điều đó sẽ biến nó thành của Kẻ tấn công. Công cụ.

Một ý tưởng thú vị là bài viết của Dankrad Feist về tối đa hóa việc đặt cược thanh khoản. Đầu tiên, hãy cắn răng và giả định rằng nếu Ethereum bị tấn công 51% thì chỉ 5% số ETH bị tấn công có thể bị chém. Đây là một sự đánh đổi hợp lý; với hơn 26 triệu ETH hiện đang được đặt cược, chi phí tấn công một phần ba số đó (~8 triệu ETH) là quá cao, đặc biệt khi xem xét có bao nhiêu cuộc tấn công “ngoài mô hình” có thể được thực hiện tại một thời điểm. chi phí thấp hơn. Trên thực tế, những sự đánh đổi tương tự đã được khám phá trong đề xuất của “siêu ủy ban” để thực hiện tính chính xác của một vị trí.

Nếu chúng tôi chấp nhận rằng chỉ 5% ETH trong cuộc tấn công bị cắt giảm thì hơn 90% ETH đặt cược sẽ không bị ảnh hưởng bởi việc cắt giảm, vì vậy chúng có thể được sử dụng làm mã thông báo đặt cược chất lỏng có thể thay thế trong giao thức, sau đó có thể được sử dụng bởi các ứng dụng khác.

Con đường này thật thú vị. Nhưng nó vẫn để lại một câu hỏi: chính xác thì cái gì được gói gọn? Rocket Pool hoạt động rất giống nhau: mỗi nhà điều hành nút cung cấp một số tiền và những người đặt cược thanh khoản sẽ cung cấp phần còn lại. Chúng ta có thể chỉ cần điều chỉnh một số hằng số để giới hạn hình phạt cắt giảm tối đa xuống còn 2 ETH và rETH hiện tại của Rocket Pool sẽ không có rủi ro.

Với những điều chỉnh giao thức đơn giản, chúng ta cũng có thể làm được những điều thông minh khác. Ví dụ: giả sử chúng tôi muốn một hệ thống có hai “cấp” đặt cược: người vận hành nút (yêu cầu tài sản thế chấp cao) và người gửi tiền (không có yêu cầu tài sản thế chấp tối thiểu, có thể tham gia và rời đi bất cứ lúc nào), nhưng chúng tôi vẫn muốn cung cấp một mẫu ngẫu nhiên Ủy ban gửi tiền có quyền ngăn chặn việc tập trung hóa các nhà khai thác nút, chẳng hạn như đề xuất danh sách các giao dịch phải được đưa vào (vì lý do chống kiểm duyệt), kiểm soát việc lựa chọn nhánh trong khi rò rỉ không hoạt động hoặc yêu cầu chữ ký trên các khối. Điều này có thể được thực hiện theo cách về cơ bản không còn giao thức bằng cách điều chỉnh giao thức để yêu cầu mỗi trình xác thực cung cấp (i) khóa đặt cược thông thường và (ii) địa chỉ ETH có thể được sử dụng trong mỗi vị trí được gọi để xuất ra khóa cam kết phụ. Giao thức sẽ trao quyền cho cả hai khóa, nhưng cơ chế chọn khóa thứ hai trong mỗi vị trí có thể được giao cho giao thức nhóm đặt cược. Có thể vẫn tốt hơn nếu đóng gói trực tiếp một số chức năng, nhưng cần lưu ý rằng không gian thiết kế “bao gồm một số thứ và để lại những thứ khác cho người dùng” vẫn tồn tại.

Đóng gói nhiều tiền biên dịch hơn

Hợp đồng được biên dịch trước (hoặc “hợp đồng được biên dịch trước”) là các hợp đồng Ethereum triển khai các hoạt động mã hóa phức tạp, với logic được triển khai nguyên bản trong mã máy khách thay vì mã hợp đồng thông minh EVM. Tiền mã hóa là một thỏa hiệp được áp dụng ngay từ khi bắt đầu phát triển Ethereum: do chi phí hoạt động của máy ảo quá lớn đối với một số mã rất phức tạp và có tính chuyên môn cao nên chúng tôi có thể triển khai một số ứng dụng quan trọng bằng mã gốc. Ngày nay, về cơ bản, điều này bao gồm một số hàm băm cụ thể và các phép toán đường cong elip.

Hiện đang có nỗ lực bổ sung tính năng biên dịch trước cho secp 256 r 1, một đường cong elip hơi khác so với secp 256 k 1 được sử dụng cho các tài khoản ethereum cơ bản, được sử dụng rộng rãi vì nó được hỗ trợ tốt bởi các mô-đun phần cứng đáng tin cậy. Sử dụng nó để tăng cường bảo mật ví. Trong những năm gần đây, cộng đồng cũng đã nỗ lực bổ sung tính năng biên dịch trước cho BLS-12-377, BW 6-761, ghép nối tổng quát và các tính năng khác.

Lập luận phản đối những lời kêu gọi có nhiều trình biên dịch trước này là nhiều trình biên dịch trước được thêm vào trước đó (ví dụ: RIPEMD và BLAKE) cuối cùng lại được sử dụng ít hơn nhiều so với dự kiến ​​và chúng ta nên rút kinh nghiệm từ điều này. Thay vì bổ sung thêm tính năng biên dịch trước cho các hoạt động cụ thể, có lẽ chúng ta nên tập trung vào cách tiếp cận nhẹ nhàng hơn dựa trên các ý tưởng như EVM- MAX  và đề xuất SIMD Hibernate-Nhưng-Luôn-Resumable, cho phép triển khai EVM chạy với chi phí thấp hơn. thực thi một loạt các lớp mã. Có lẽ ngay cả quá trình biên dịch trước ít được sử dụng hiện tại cũng có thể bị loại bỏ và thay thế bằng việc triển khai mã EVM (chắc chắn kém hiệu quả hơn) cho các chức năng tương tự. Điều đó nói lên rằng, vẫn có khả năng có các hoạt động mã hóa cụ thể đủ giá trị để được tăng tốc, do đó, việc thêm chúng dưới dạng biên dịch trước là điều hợp lý.

Chúng ta đã học được gì từ tất cả những điều này?

Mong muốn gói gọn càng ít càng tốt là điều dễ hiểu và tốt; nó bắt nguồn từ  truyền thống triết học Unix  về việc tạo ra phần mềm tối giản có thể dễ dàng thích ứng với các nhu cầu khác nhau của người dùng và tránh tai họa phình to phần mềm. Tuy nhiên, blockchain không phải là hệ điều hành máy tính cá nhân mà là một hệ thống xã hội. Điều này có nghĩa là việc đóng gói một số chức năng nhất định trong giao thức là hợp lý.

Trong nhiều trường hợp, những ví dụ khác này tương tự như những gì chúng ta đã thấy trong phần tóm tắt tài khoản. Nhưng chúng tôi cũng học được một số bài học mới:

• Chức năng đóng gói có thể giúp tránh rủi ro tập trung ở các khu vực khác của ngăn xếp :

Thông thường, việc giữ giao thức cơ sở ở mức tối thiểu và đơn giản sẽ đẩy sự phức tạp ra một số hệ sinh thái bên ngoài giao thức. Từ góc độ triết lý Unix, điều này là ổn. Tuy nhiên, đôi khi có nguy cơ hệ sinh thái ngoài giao thức sẽ trở nên tập trung, thường là (nhưng không chỉ) do chi phí cố định cao. Đóng gói đôi khi có thể làm giảm sự tập trung trên thực tế.

• Việc đóng gói quá nhiều có thể làm tăng quá mức gánh nặng quản trị và tin cậy của giao thức :

Đây là chủ đề của bài viết trước về “Đừng quá tải sự đồng thuận Ethereum”: nếu việc đóng gói một tính năng cụ thể làm suy yếu mô hình tin cậy và khiến Ethereum trở nên “chủ quan” hơn, thì điều này sẽ làm suy yếu Ethereum. Trong những trường hợp này, tốt hơn là nên có chức năng cụ thể như một cơ chế trên Ethereum thay vì cố gắng đưa nó vào chính Ethereum. Nhóm bộ nhớ được mã hóa là ví dụ điển hình nhất ở đây, có thể hơi khó đóng gói, ít nhất là cho đến khi mã hóa độ trễ được cải thiện.

• Việc đóng gói quá nhiều có thể làm cho giao thức trở nên quá phức tạp :

Độ phức tạp của giao thức là rủi ro hệ thống tăng lên khi thêm quá nhiều tính năng vào một giao thức. Biên dịch trước là ví dụ tốt nhất.

• Chức năng đóng gói có thể phản tác dụng về lâu dài vì nhu cầu của người dùng là không thể đoán trước :

Một tính năng mà nhiều người cho là quan trọng và sẽ được nhiều người dùng sử dụng có lẽ không được sử dụng thường xuyên trong thực tế.

Ngoài ra, đặt cược thanh khoản, ZK-EVM và các ví dụ được biên dịch trước cho thấy khả năng có một con đường trung gian: khả năng lưu trữ khả thi ở mức tối thiểu. Giao thức không cần gói gọn toàn bộ chức năng nhưng có thể chứa các phần cụ thể nhằm giải quyết các thách thức chính, giúp chức năng dễ triển khai mà không quá hoang tưởng hoặc quá hẹp. Những ví dụ bao gồm:

• Thay vì đóng gói một hệ thống đặt cược thanh khoản hoàn chỉnh, tốt hơn là nên thay đổi các quy tắc phạt đặt cược để làm cho việc đặt cược thanh khoản không cần sự tin cậy trở nên khả thi hơn;
• Thay vì đóng gói nhiều bộ tiền biên dịch hơn, EVM-MAX và/hoặc SIMD nên được đóng gói để làm cho lớp hoạt động rộng hơn dễ thực hiện hiệu quả hơn;
• Thay vì gói gọn toàn bộ khái niệm tổng hợp, bạn có thể chỉ gói gọn xác minh EVM.

Chúng ta có thể mở rộng sơ đồ trước đó như sau:

Đôi khi việc đóng gói một cái gì đó là hợp lý và việc loại bỏ các trình biên dịch trước hiếm khi được sử dụng là một ví dụ. Việc trừu tượng hóa tài khoản nói chung, như đã đề cập trước đó, cũng là một hình thức giải đóng gói quan trọng. Nếu chúng tôi muốn hỗ trợ khả năng tương thích ngược cho người dùng hiện tại, cơ chế này thực sự có thể tương tự một cách đáng ngạc nhiên với cơ chế biên dịch trước đã được hủy gói: một trong các đề xuất là EIP-5003, cho phép EOA chuyển đổi tài khoản của họ để có cùng ( hoặc tốt hơn) hợp đồng chức năng.

Những tính năng nào nên được đưa vào giao thức và những tính năng nào nên để lại cho các lớp khác của hệ sinh thái là một sự đánh đổi phức tạp. Sự đánh đổi này dự kiến ​​sẽ tiếp tục được cải thiện theo thời gian khi sự hiểu biết của chúng tôi về nhu cầu của người dùng cũng như bộ ý tưởng và công nghệ sẵn có tiếp tục được cải thiện.