**Những triết lý ban đầu của chủ nghĩa tối giản giao thức **
Trong lịch sử ban đầu của cái mà sau đó được gọi là "Ethereum 2.0", có một mong muốn mạnh mẽ để tạo ra một giao thức sạch sẽ, đơn giản và thẩm mỹ, cố gắng tự xây dựng với ít nhất có thể và để lại gần như tất cả các loại công việc đó cho người dùng. Lý tưởng nhất, giao thức chỉ là một máy ảo và xác thực một đoạn chỉ là một cuộc gọi máy ảo.
"Chức năng chuyển đổi trạng thái" (hàm xử lý đoạn) sẽ chỉ là một cuộc gọi VM duy nhất và tất cả các logic khác sẽ xảy ra thông qua 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 tốt của mô hình này là thậm chí toàn bộ hard fork có thể được mô tả như một giao dịch duy nhất cho hợp đồng bộ xử lý khối sẽ được phê duyệt bởi quản trị ngoài chuỗi hoặc trên chuỗi và sau đó chạy với các đặc quyền nâng cao.
Những cuộc thảo luận này trong năm 2015 áp dụng đặc biệt 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 mở rộng quy mô, ý tưởng là cố gắng tạo ra một hình thức trừu tượng tối đa của tỷ lệ cảm thấy giống như một phần mở rộng tự nhiên của biểu đồ trên. 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 bằng một số loại chức năng tính toán mở rộng rất chung chung. Từ quan điểm của máy ảo, cuộc gọi đi vào một số hệ thống con riêng biệt và trả về câu trả lời đúng một cách kỳ diệu sau một thời gian.
Chúng tôi đã khám phá dòng suy nghĩ này một cách ngắn gọn, nhưng nhanh chóng từ bỏ vì chúng tôi quá tập trung vào việc xác minh rằng bất kỳ loại mở rộng blockchain nào cũng có thể. Mặc dù 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 có thể cho việc mở rộng quy mô Ethereum thực sự trông rất gần với tầm nhìn này! Mặt khác, đối với sự trừu tượng hóa tài khoản, chúng tôi đã biết ngay từ đầu rằng một số loại triển khai là có thể, vì vậy nghiên cứu ngay lập tức bắt đầu cố gắng đưa một cái gì đó càng gần càng tốt đến điểm khởi đầu thuần túy của "giao dịch chỉ là một lời kêu gọi" vào thực tế.
Giữa việc xử lý giao dịch và thực hiện cuộc gọi EVM cơ bản thực tế từ địa chỉ người gửi, có rất nhiều mã soạn sẵn và nhiều mã soạn sẵn hơn sau đó. Làm thế nào để chúng ta giảm mã này càng gần bằng không càng tốt?
Một trong những mã chính ở đây là validate_transaction(state, tx), chịu trách nhiệm kiểm tra xem giao dịch có nonce và chữ ký chính xác hay không. Ngay từ đầu, mục tiêu thực tế của trừu tượng hóa tài khoản là cho phép người dùng thay thế xác minh không gia tăng và ECDSA cơ bản 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 kiến trúc lại áp dụng \ _transaction như một cuộc gọi EVM đơn giản không chỉ là một nhiệm vụ "mã sạch vì mục đích làm cho mã sạch"; Thay vào đó, đó là về việc di 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, nhấn mạnh rằng áp dụng \ _transaction chứa càng ít logic cố định càng tốt cuối cùng 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 bao gồm nguyên trạng, nó sẽ làm giảm độ phức tạp của EVM với chi phí tăng đáng kể độ phức tạp của các phần khác của ngăn xếp Ethereum, yêu cầu mã giống hệt nhau về cơ bản được viết ở nơi khác, ngoại trừ việc giới thiệu các danh mục kỳ lạ hoàn toàn mới, chẳng hạn như cùng một giao dịch với cùng một số 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.
Nhiều vấn đề về vô hiệu hóa trong trừu tượng hóa tài khoản. Một giao dịch được bao gồm trên chuỗi có thể làm mất hiệu lực hàng nghìn giao dịch khác trong mempool, làm cho mempool dễ dàng tràn ngập với giá rẻ.
Kể từ đó, sự trừu tượng hóa tài khoản đã phát triển theo từng giai đoạn. EIP-86 sau đó trở thành EIP-208 và cuối cùng là EIP-2938 thực tế.
Tuy nhiên, EIP-2938 là bất cứ điều gì ngoài tối giản. Nội dung của nó bao gồm:
· Các loại giao dịch mới
· Biến toàn cầu cho ba phạm vi giao dịch mới
· Hai opcode mới, bao gồm opcode PAYgas rất cồng kềnh để xử lý kiểm tra giá gas và giới hạn gas, thực hiện các điểm ngắt dưới dạng EVM và tạm thời lưu trữ ETH với phí một lần
· Một tập hợp phức tạp các chiến lược khai thác và phát sóng lại, bao gồm danh sách các opcode bị cấm trong giai đoạn xác minh giao dịch
Để thực hiện trừu tượng hóa tài khoản mà không liên quan đến 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 các máy khách Ethereum và thực hiện hợp nhất), EIP-2938 cuối cùng đã được kiến trúc lại thành ERC-4337 hoàn toàn ngoài giao thức.
Bởi vì đây là một ERC, 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". Như vậy...... Vấn đề đã được giải quyết chưa? Hóa ra đây không phải là trường hợp. Lộ trình trung hạn hiện tại của ERC-4337 thực sự liên quan đến việc cuối cùng biến phần lớn ERC-4337 thành một tập hợp các tính năng giao thức, đây là một ví dụ hướng dẫn hữu ích về lý do tại sao con đường này nên được xem xét.
** 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 quả khí: Bất kỳ hoạt động nào được thực hiện bên trong EVM đều dẫn đến một số mức chi phí máy ảo, bao gồm cả sự thiếu hiệu quả khi sử dụng các tính năng đắt tiền 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 lên tới ít nhất 20.000 khí hoặc nhiều hơn. Đưa các thành phần này vào một 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 vào lệnh" ERC-4337 có lỗi đủ đáng sợ, tất cả các ví tương thích ERC-4337 có thể thấy tất cả tiền của họ cạn kiệt. Thay thế hợp đồng bằng chức năng trong giao thức tạo ra nghĩa vụ ngầm để sửa lỗi mã thông qua hard fork, do đó loại bỏ nguy cơ tiền của người dùng cạn kiệt.
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 "bundler" đóng gói một tập hợp các hành động của người dùng vào một giao dịch. 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 tế gửi giao dịch, làm cho nó hoạt động giống như EOA.
Chống kiểm duyệt: Một trong những thách thức của việc tách 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. Vấn đề này có thể được giảm bớt đáng kể trong một thế giới nơi giao thức Ethereum có thể nhận ra một giao dịch duy nhất, 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 đóng gói "hoạt động của người dùng" trong một giao dịch duy nhất, làm cho hoạt động của người dùng không rõ ràng với giao thức Ethereum; Do đó, danh sách bao gồm được cung cấp bởi giao thức Ethereum sẽ không thể cung cấp khả năng chống kiểm duyệt cho các hoạt động của người dùng ERC-4337. Đóng gói ERC-4337 và làm cho hành động của người dùng trở thành một loại giao dịch "thích hợp" sẽ giải quyết vấn đề này.
Điều đáng nói là ở dạng hiện tại, ERC-4337 đắt hơn nhiều so với giao dịch Ethereum "cơ bản": chi phí giao dịch là 21.000 gas, trong khi ERC-4337 có giá khoảng 42.000 gas.
Về mặt lý thuyết, có thể điều chỉnh hệ thống chi phí khí EVM cho đến khi chi phí trong thỏa thuận và chi phí truy cập ngoài giao thức để lưu trữ phù hợp; Khi các loại hoạt động chỉnh sửa lưu trữ khác rẻ hơn, không có lý do gì để chuyển ETH ở mức 9000 gas. Trên thực tế, hai EIP liên quan đến việc chuyển đổi cây Verkle sắp tới thực sự cố gắng làm điều đó. Nhưng ngay cả khi chúng ta làm như vậy, có một lý do rõ ràng tại sao chức năng giao thức đóng gói chắc chắn sẽ rẻ hơn nhiều so với mã EVM, bất kể EVM trở nên hiệu quả như thế nào: mã đóng gói không cần phải trả tiền gas để tải trước.
Ví ERC-4337 đầy đủ chức năng rất lớn và việc triển khai biên dịch và đưa nó 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 mỗi ví riêng lẻ gọi nó, nhưng bạn vẫn cần truy cập mã trong mọi khối sử dụng nó. Theo EIP chi phí khí cây Verkle, 12.800 byte sẽ tạo thành 413 khối và việc truy cập các khối này sẽ yêu cầu trả gấp 2 lần chi nhánh nhân chứng \ _cost (tổng cộng 3.800 khí) và 413 lần khối nhân chứng \ _cost (tổng cộng 82.600 khí). Và điều đó thậm chí không bắt đầu đề 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 cây Verkle).
Điều này dẫn đến vấn đề: chi phí gas để thực sự truy cập các mã này bằng cách nào đó phải được khấu hao trên toàn 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 nó đắt hơn nhiều so với các giao dịch khác. Đóng gói trong giao thức sẽ cho phép các thư viện chia sẻ công cộng này là một phần của giao thức và có thể truy cập miễn phí cho tất cả mọi người.
Chúng ta có thể học được gì từ ví dụ này và khi nào bao bì sẽ phổ biến hơn? **
Trong ví dụ này, chúng ta thấy một số lý do khác nhau để đóng gói khía cạnh trừu tượng hóa tài khoản trong 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 ra rì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 có vẻ như mỗi khối có rất nhiều chi phí cố định. 244, 100 gas để tải mã ví tiêu chuẩn là một chuyện; Nhưng tổng hợp có thể thêm hàng trăm ngàn gas vào xác thực ZK-SNARK, cũng như chi phí xác thực bằng chứng chuỗi trên chuỗi. Không có cách nào để tính phí người dùng cho các chi phí này mà không gây ra nhiều sự thiếu hiệu quả của thị trường và việc dịch 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 đều có thể truy cập miễn phí sẽ giải quyết tốt vấn đề này.
Phản hồi trên toàn cộng đồng đối với lỗi mã. Nếu một số đoạn mã đượ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, cộng đồng blockchain thường có ý nghĩa hơn khi chịu trách nhiệm về một hard fork để sửa bất kỳ lỗi nào phát sinh. ERC-4337 giới thiệu một lượng lớn mã được chia sẻ trên toàn cầu và việc sửa lỗi trong mã thông qua hard fork chắc chắn sẽ hợp lý hơn về lâu dài so với việc khiến người dùng mất nhiều ETH.
Đôi khi, một hình thức mạnh mẽ hơn có thể đạt được bằng cách tận dụng trực tiếp chức năng của giao thức. Ví dụ chính ở đây là 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 phương pháp bên ngoài giao thức và để các hoạt động cấp người dùng thực sự được hưởng lợi từ danh sách bao gồm trong giao thức, một hoạt động cấp người dùng duy nhất cần phải "có thể đọc được" đối với giao thức. 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 2017 đã trừu tượng hóa tài khoản khóa cổ phần, đã bị bỏ rơi để ủng hộ việc đóng gói BLS, vì BLS hỗ trợ cơ chế "tổng hợp" phải được triển khai ở cấp độ giao thức và mạng, có thể giúp 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 trừu tượng hóa tài khoản trong giao thức vẫn là một sự "đóng gói" rất lớn so với tình hình hiện tại. Ngày nay, các giao dịch Ethereum hàng đầu 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 một chữ ký đường cong elip 256k1 secp duy nhất. Trừu tượng hóa tài khoản loại bỏ điều này và để lại các tiêu chí xác thực cho người dùng xác định. Vì vậy, trong câu chuyện về trừu tượng hóa tài khoản này, chúng ta cũng thấy lập luận lớn nhất chống lại việc đóng gói: tính linh hoạt để đáp ứng nhu cầu của những người dùng khác nhau.
Hãy làm rõ câu chuyện này hơn nữa 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 coi là gói gọn. Chúng tôi sẽ đặc biệt chú ý đến: ZK-EVM, tách người đề xuất-người xây dựng, mempool riêng, đặt cọc thanh khoản và biên dịch trước.
Gói 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 của giao thức Ethereum: ZK-EVM. Hiện tại, chúng tôi có một số lượng lớn ZK-rollups, 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à nhiều hơn nữa.
Một cuộc tranh cãi gần đây trong không gian EVM ZK-rollup liên quan đến cách xử lý các lỗi có thể xảy ra trong mã ZK. Hiện tại, tất cả các hệ thống đang chạy 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 để khuyến khích các dự án làm rõ mức độ tin cậy của họ vào hệ thống chứng nhận, cũng như trong Hội đồng Bảo an, và giảm dần thẩm quyền của họ đối với tổ chức theo thời gian.
Trong trung hạn, các bản tổng hợp có thể dựa vào nhiều hệ thống chứng thực và Hội đồng Bảo an sẽ chỉ có quyền lực trong những trường hợp cực đoan khi hai hệ thống chứng thực khác nhau khác nhau.
Tuy nhiên, có cảm giác rằng một số công việc cảm thấy 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ý lỗi trong quá trình triển khai: nếu có lỗi, máy khách sẽ cập nhật để sửa lỗi và sau đó chuỗi sẽ tiếp tục hoạt động. Từ quan điểm của khách hàng lỗi, có vẻ như các khối đã được hoàn thiện sẽ không còn được xác nhận, nhưng ít nhất chúng ta sẽ không thấy người dùng mất tiền. Tương tự, nếu các bản tổng hợp chỉ muốn duy trì vai trò tương đương với EVM, thì họ cần thực hiện 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 họ để phù hợp với việc nâng cấp lên lớp cơ sở Ethereum, điều này cảm thấy sai vì cuối cùng chúng được xây dựng trên chính lớp cơ sở Ethereum, biết khi nào cần nâng cấp và theo quy tắc mới nào.
Vì các L2 ZK-EVM này về cơ bản sử dụng chính xác các EVM giống như Ethereum, chúng ta có thể bằng cách nào đó 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 ngoại lệ như lỗi và nâng cấp bằng cách áp dụng sự đồng thuận xã hội của Ethereum, như chúng ta đã làm với chính việc triển khai EVM lớp cơ sở không?
Đây là một chủ đề quan trọng và đầy thách thức.
Một chủ đề có thể tranh luận về tính khả dụng của dữ liệu trong ZK-EVM gốc là tính trạng thái. Nếu ZK-EVM không cần mang dữ liệu "nhân chứng", hiệu quả dữ liệu của chúng sẽ cao hơn nhiều. Đó 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ể chỉ cần giả định rằng người chứng minh có quyền truy cập vào nó và không phải cung cấp lại. Nó không chỉ là về việc không tải lại bộ nhớ và mã; Nó chỉ ra rằng nén trạng thái có thể tiết kiệm tới 3x dữ liệu so với nén không trạng thái nếu một bản tổng hợp nén dữ liệu một cách chính xác.
Điều này có nghĩa là đối với biên dịch trước ZK-EVM, chúng tôi có hai tùy chọn:
Việc 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 đoạn. Điều này có nghĩa là prover có thể không có trạng thái, nhưng nó cũng có nghĩa là sử dụng ZK-rollup được biên dịch sẵn này đắt hơn nhiều so với sử dụng rollup với mã tùy chỉnh.
Biên dịch trước cho phép con trỏ trỏ đến dữ liệu đã được thực thi, sử dụng hoặc tạo trước đó. Điều này làm cho ZK-rollup gần như tối ưu, nhưng nó phức tạp hơn và giới thiệu một trạng thái mới phải được lưu trữ bởi prover.
Chúng ta có thể học được gì từ điều này? Có một lý do chính đáng để bằng cách nào đó gói gọn xác minh ZK-EVM: 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 cân nhắc nhiều triển khai và sự đồng thuận xã hội ngoài chuỗi của nó trên L1 để thực thi EVM, điều này cảm thấy sai, nhưng L2 làm chính xác cùng một công việc phải thực hiện các 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 vấn đề lớn trong các chi tiết: có nhiều phiên bản khác nhau của ZK-EVM, khác nhau về chi phí và lợi ích. Sự phân biệt giữa trạng thái và không quốc tịch chỉ làm trầy xước bề mặt; Cố gắng hỗ trợ "gần như EVM", mã tùy chỉnh đã được chứng minh bởi các hệ thống khác, có thể phơi bày nhiều không gian thiết kế hơn. Do đó, việc đóng gói ZK-EVM mang lại cả hứa hẹn và thách thức.
** Wrapper và Builder Separation (ePBS) **
Sự gia tăng của MEV đã làm cho sản xuất khối trở thành một hoạt động kinh tế quy mô lớn, với những người tham gia phức tạp 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, chỉ đơn giản là quan sát mempool của các 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 sơ đồ tách biệt người đề xuất-người xây dựng ngoài giao thức như MEV-Boost, cho phép người xác nhận thông thường ("người đề xuất") thuê ngoài xây dựng khối cho những người tham gia chuyên biệt ("nhà xây dựng").
Tuy nhiên, MEV-Boost đưa ra các giả định tin tưởng vào một lớp người tham gia mới được gọi là rơle. Trong hai năm qua, đã có nhiều đề xuất để tạo ra "PBS đóng 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: PBS được xây dựng trực tiếp với các tính năng giao thức mạnh hơn (theo nghĩa là có các giả định tin cậy yếu hơn) so với PBS được xây dựng mà không có chúng. Điều này tương tự như trường hợp của các nhà tiên tri giá trong giao thức đóng gói - mặc dù trong trường hợp này, cũng có sự 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ó 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 của nhiều ứng dụng dễ bị tấn công kinh tế, chẳng hạn như giao dịch phủ đầu.
Gần đây, đã có một số dự án dành riêng cho việc tạo ra "mempool riêng tư" (hoặc "mempool được mã hóa") mã hóa các giao dịch của người dùng cho đến khi chúng được chấp nhận không thể đảo ngược vào một khối.
Tuy nhiên, vấn đề là các chương trình như vậy đòi hỏi một loại mã hóa đặc biệt: để ngăn người dùng tràn ngập hệ thống và giải mã nó trước, mã hóa phải được tự động giải mã sau khi giao dịch thực sự được chấp nhận không thể đảo ngược.
Để đạt được hình thức mã hóa này, có nhiều kỹ thuật đánh đổi khác nhau. Jon Charbonneau đã từng nói rất hay:
Mã hóa các toán tử tập trung, chẳng hạn như Flashbots Protect.
mã hóa khóa thời gian, có thể được giải mã bởi bất kỳ ai sau một bước tính toán tuần tự nhất định và không thể song song;
Mã hóa ngưỡng, tin tưởng một ủy ban đa số trung thực để giải mã dữ liệu. Để biết các khuyến nghị cụ thể, hãy xem Khái niệm chuỗi đèn hiệu đóng.
Phần cứng đáng tin cậy, chẳng hạn như SGX.
Thật không may, mỗi mã hóa có những điểm yếu khác nhau. Mặc dù đối với mọi giải pháp, có một tập hợp con người dùng sẵn sàng tin tưởng nó, nhưng không có giải pháp nào đủ tin cậy để nó thực sự được Lớp 1 chấp nhận. Vì vậy, ít nhất là cho đến khi mã hóa độ trễ đượ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 giao dịch chống nâng cao ở Lớp 1 có vẻ 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 **
Một nhu cầu phổ biến đối với người dùng Ethereum DeFi là khả năng sử dụng ETH của họ đồng thời để đặt cọc và làm tài sản thế chấp trong các ứng dụng khác. Một nhu 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 sự phức tạp của việc chạy một nút và giữ cho 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à 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 đã bắt đầu làm như vậy. Tuy nhiên, đặt cọc thanh khoản có một số cơ chế tập trung tự nhiên trong công việc: mọi người tự nhiên chuyển sang phiên bản đặt cọc ETH lớn nhất vì nó quen thuộc và thanh khoản nhất.
Mỗi phiên bản đặt cọc ETH yêu cầu một số cơ chế để xác định ai có thể là nhà điều hành nút cơ bản. Nó không thể là không giới hạn, vì sau đó những kẻ tấn công sẽ tham gia và khuếch đại cuộc tấn công bằng tiền của người dùng. Hiện tại, hai công ty hàng đầu là Lido, có nhà điều hành nút danh sách trắng DAO và Rocket Pool, cho phép bất kỳ ai chạy một nút có 8 ETH được gửi. Hai phương pháp có rủi ro khác nhau: cách tiếp cận Rocket Pool cho phép kẻ tấn công thực hiện các cuộc tấn công 51% vào mạng và buộc người dùng phải trả phần lớn chi phí; Đối với cách tiếp cận DAO, nếu một mã thông báo đặt cọc nhất định chiếm ưu thế, nó sẽ dẫn đến một tiện ích quản trị duy nhất, có khả năng bị tấn công kiểm soát một phần đáng kể của tất cả các trình xác thực Ethereum. Để chắc chắn, các giao thức như Lido đã có các biện pháp phòng ngừa, nhưng một lớp phòng thủ có thể 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 đặt cọc thanh khoản đa dạng để giảm khả năng rủi ro hệ thống từ một công ty duy nhất. Tuy nhiên, về lâu dài, đây là một trạng thái cân bằng bấp bênh, và thật nguy hiểm khi dựa quá nhiều vào áp lực đạo đức để giải quyết vấn đề. Một câu hỏi tự nhiên được đặt ra: liệu có hợp lý khi đóng gói một số loại chức năng trong giao thức để làm cho việc đặt cọc thanh khoản ít tập trung hơn không?
Câu hỏi chính ở đây là: loại chức năng trong giao thức nào? Vấn đề với việc chỉ đơn giản là tạo ra một mã thông báo "đặt cọc ETH" có thể thay thế trong giao thức là nó phải có quản trị toàn Ethereum được đóng gói để chọn người chạy các nút hoặc nó đang mở, nhưng điều này biến nó thành một công cụ cho những kẻ tấn công.
Một ý tưởng thú vị là bài viết của Dankrad Feist về tối đa hóa đặt cọc thanh khoản. Đầu tiên, hãy cắn viên đạn và nếu Ethereum bị tấn công bởi 51%, chỉ có 5% ETH tấn công có thể bị tịch thu. Đâ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, một phần ba trong số đó (khoảng 8 triệu ETH) chi phí tấn công là quá mức, đặc biệt là 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 với chi phí thấp hơn. Trên thực tế, sự đánh đổi tương tự đã được khám phá trong đề xuất của Super Commission để thực hiện tính cuối cùng của một vị trí.
Nếu chúng tôi chấp nhận rằng chỉ có 5% ETH tấn công bị tịch thu, thì hơn 90% ETH được đặt cọc sẽ không bị ảnh hưởng bởi việc tịch thu, vì vậy chúng có thể được sử dụng làm mã thông báo đặt cọc thanh khoản có thể thay thế trong giao thức và sau đó được sử dụng bởi các ứng dụng khác.
Con đường thật thú vị. Nhưng nó vẫn để lại câu hỏi: chính xác những gì được gói gọn? Rocket Pool hoạt động rất giống nhau: mỗi nhà khai thác nút cung cấp một số tiền và người đặt cọc thanh khoản 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 mức phạt tối đa là 2 ETH và rETH hiện có của Rocket Pool sẽ trở nên 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 những việc thông minh khác. Ví dụ: giả sử chúng ta muốn một hệ thống có hai "lớp" đặt cược: nhà khai thác 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 và 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 ngăn chặn sự tập trung của các nhà khai thác nút bằng cách trao quyền cho một ủy ban người gửi tiền được lấy mẫu ngẫu nhiên, 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 ngã ba trong thời gian rò rỉ không hoạt động hoặc yêu cầu ký khối. Điều này có thể đạt được theo cách về cơ bản tách ra khỏi giao thức bằng cách tinh 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 gọi trên mỗi khe để xuất khóa đặt cọc thứ cấp. Giao thức sẽ cung cấp năng lượng cho cả hai khóa, nhưng cơ chế chọn khóa thứ hai trong mỗi khe có thể được để lại cho giao thức nhóm đặt cọc. Vẫn có thể tốt hơn để đóng gói trực tiếp một số tính năng, nhưng điều đáng chú ý là không gian thiết kế "bao gồm một số thứ và để lại mọi thứ khác cho người dùng" tồn tại.
** Đóng gói thêm các bản tổng hợp trước **
Biên dịch sẵn (hoặc "hợp đồng biên dịch trước") là các hợp đồng Ethereum thực hiện các hoạt động mật mã phức tạp, 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 sự thỏa hiệp được thông qua khi bắt đầu phát triển Ethereum: vì chi phí của một máy ảo quá lớn đối với một số mã rất phức tạp và chuyên dụng cao, chúng tôi có thể thực hiện một số hoạt động chính trong mã cục bộ có giá trị đối với các ứng dụng quan trọng để làm cho nó nhanh hơn. Ngày nay, điều này về cơ bản bao gồm một số hàm băm cụ thể và các phép toán đường cong elip.
Hiện tại có một sự thúc đẩy để thêm precompilation cho secp 256 R1, một đường cong elip hơi khác so với secp 256 K1 cho các tài khoản Ethereum cơ bản, vì nó được hỗ trợ tốt bởi các mô-đun phần cứng đáng tin cậy, vì vậy việc sử dụng rộng rãi nó có thể cải thiện bảo mật ví. Trong những năm gần đây, cộng đồng cũng đã thúc đẩy việc bổ sung các bản 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.
Đối lập với những yêu cầu này đối với các tệp được biên dịch sẵn hơn là nhiều bản biên dịch trước được thêm vào trước đó (ví dụ: RIPEMD và BLAKE) cuối cùng sử dụng ít hơn nhiều so với dự kiến và chúng ta nên học hỏi từ chúng. Thay vì thêm nhiều 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 một cách tiếp cận nhẹ nhàng hơn dựa trên các ý tưởng như EVM-MAX và các đề xuất SIMD không hoạt động nhưng luôn có thể phục hồi, điều này sẽ cho phép triển khai EVM thực thi một loạt các lớp mã với chi phí thấp hơn. Có lẽ ngay cả việc biên dịch trước hiếm khi được sử dụng hiện có cũng có thể bị loại bỏ và thay thế bằng việc triển khai (chắc chắn kém hiệu quả hơn) mã EVM của cùng một chức năng. Điều đó nói rằng, vẫn có thể có các hoạt động mật mã cụ thể đủ giá trị để tăng tốc, vì vậy thật hợp lý khi thêm chúng dưới dạng biên dịch sẵn.
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ó xuất phát 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 nghi với các nhu cầu khác nhau của người dùng và tránh lời nguyền của phần mềm phình to. Tuy nhiên, blockchain không phải là một 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à nó có ý nghĩa để đóng gói một số chức năng nhất định trong giao thức.
Trong nhiều trường hợp, các ví dụ khác này tương tự như những gì chúng ta thấy trong bả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:
Đóng gói có thể giúp tránh nguy cơ tập trung hóa ở những nơi khác trong ngăn xếp:
Thông thường, việc giữ cho giao thức cơ bản tối thiểu và đơn giản sẽ đẩy sự phức tạp vượt ra ngoài một số giao thức của hệ sinh thái. Từ quan điểm triết học Unix, điều này là tốt. Tuy nhiên, đôi khi có rủi ro là các hệ sinh thái ngoài giao thức sẽ tập trung, thường (nhưng không chỉ) vì 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ế.
Đóng gói quá nhiều nội dung có thể mở rộng quá mức gánh nặng tin cậy và quản trị trên giao thức:
Đây là chủ đề của một bài viết trước về "Đừng làm quá tải sự đồng thuận của Ethereum": nếu việc đóng gói một chức năng cụ thể làm suy yếu mô hình tin cậy và làm cho Ethereum nói chung trở nên "chủ quan" hơn, nó sẽ làm suy yếu tính trung lập đáng tin cậy của Ethereum. Trong những trường hợp này, tốt hơn là trình bày một tính năng cụ thể như một cơ chế trên Ethereum hơn là cố gắng giới thiệu nó với chính Ethereum. Ở đây, các nhóm bộ nhớ được mã hóa là ví dụ tốt nhất và có thể hơi khó đóng gói, ít nhất là cho đến khi mã hóa độ trễ được cải thiện.
Đóng gói quá nhiều có thể làm phức tạp quá mức giao thức:
Độ phức tạp của giao thức là một rủi ro hệ thống có thể tăng lên bằng cách thêm quá nhiều tính năng vào giao thức. Precompilation là ví dụ tốt nhất.
Về lâu dài, chức năng đóng gói có thể phản tác dụng vì nhu cầu của người dùng 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ó thể không được sử dụng thường xuyên trong thực tế.
Ngoài ra, việc đặt cọc thanh khoản, ZK-EVM và các trường hợp được biên dịch trước cho thấy khả năng của một con đường trung gian: sự tôn thờ khả thi tối thiểu. Các giao thức không cần phải gói gọn toàn bộ chức năng, nhưng có thể chứa các phần cụ thể giải quyết các thách thức chính, làm cho chức năng dễ thực hiện mà không quá hoang tưởng hoặc quá hẹp. Ví dụ về điều này bao gồm:
Thay vì gói gọn một hệ thống cầm cố thanh khoản hoàn chỉnh, tốt hơn là thay đổi các quy tắc phạt đặt cọc để làm cho việc cầm cố thanh khoản không tin cậy trở nên khả thi hơn;
Thay vì đóng gói nhiều trình biên dịch trước, hãy đóng gói EVM-MAX và / hoặc SIMD để giúp dễ dàng triển khai hiệu quả hơn cho nhiều danh mục hoạt động hơn;
Xác minh EVM có thể được đóng gói đơn giản thay vì gói gọn toàn bộ khái niệm tổng hợp.
Chúng ta có thể mở rộng biểu đồ trước đó như sau:
Đôi khi nó có ý nghĩa để bọc một cái gì đó, và loại bỏ precompilation hiếm khi được sử dụng là một ví dụ. 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 đó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ế thực sự có thể tương tự như cơ chế đóng gói sẵn: một trong những đề xuất là EIP-5003, cho phép EOA chuyển đổi tài khoản của mình thành hợp đồng có cùng chức năng (hoặc tốt hơn).
Những tính năng nào nên được đưa vào giao thức và 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 và các ý tưởng và bộ công nghệ có sẵn tiếp tục được cải thiện.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Vitalik Buterin: Ethereum có nên gói gọn nhiều tính năng hơn không?
**Những triết lý ban đầu của chủ nghĩa tối giản giao thức **
Trong lịch sử ban đầu của cái mà sau đó được gọi là "Ethereum 2.0", có một mong muốn mạnh mẽ để tạo ra một giao thức sạch sẽ, đơn giản và thẩm mỹ, cố gắng tự xây dựng với ít nhất có thể và để lại gần như tất cả các loại công việc đó cho người dùng. Lý tưởng nhất, giao thức chỉ là một máy ảo và xác thực một đoạn chỉ là một cuộc gọi máy ảo.
"Chức năng chuyển đổi trạng thái" (hàm xử lý đoạn) sẽ chỉ là một cuộc gọi VM duy nhất và tất cả các logic khác sẽ xảy ra thông qua 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 tốt của mô hình này là thậm chí toàn bộ hard fork có thể được mô tả như một giao dịch duy nhất cho hợp đồng bộ xử lý khối sẽ được phê duyệt bởi quản trị ngoài chuỗi hoặc trên chuỗi và sau đó chạy với các đặc quyền nâng cao.
Những cuộc thảo luận này trong năm 2015 áp dụng đặc biệt 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 mở rộng quy mô, ý tưởng là cố gắng tạo ra một hình thức trừu tượng tối đa của tỷ lệ cảm thấy giống như một phần mở rộng tự nhiên của biểu đồ trên. 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 bằng một số loại chức năng tính toán mở rộng rất chung chung. Từ quan điểm của máy ảo, cuộc gọi đi vào một số hệ thống con riêng biệt và trả về câu trả lời đúng một cách kỳ diệu sau một thời gian.
Chúng tôi đã khám phá dòng suy nghĩ này một cách ngắn gọn, nhưng nhanh chóng từ bỏ vì chúng tôi quá tập trung vào việc xác minh rằng bất kỳ loại mở rộng blockchain nào cũng có thể. Mặc dù 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 có thể cho việc mở rộng quy mô Ethereum thực sự trông rất gần với tầm nhìn này! Mặt khác, đối với sự trừu tượng hóa tài khoản, chúng tôi đã biết ngay từ đầu rằng một số loại triển khai là có thể, vì vậy nghiên cứu ngay lập tức bắt đầu cố gắng đưa một cái gì đó càng gần càng tốt đến điểm khởi đầu thuần túy của "giao dịch chỉ là một lời kêu gọi" vào thực tế.
Giữa việc xử lý giao dịch và thực hiện cuộc gọi EVM cơ bản thực tế từ địa chỉ người gửi, có rất nhiều mã soạn sẵn và nhiều mã soạn sẵn hơn sau đó. Làm thế nào để chúng ta giảm mã này càng gần bằng không càng tốt?
Một trong những mã chính ở đây là validate_transaction(state, tx), chịu trách nhiệm kiểm tra xem giao dịch có nonce và chữ ký chính xác hay không. Ngay từ đầu, mục tiêu thực tế của trừu tượng hóa tài khoản là cho phép người dùng thay thế xác minh không gia tăng và ECDSA cơ bản 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 kiến trúc lại áp dụng \ _transaction như một cuộc gọi EVM đơn giản không chỉ là một nhiệm vụ "mã sạch vì mục đích làm cho mã sạch"; Thay vào đó, đó là về việc di 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, nhấn mạnh rằng áp dụng \ _transaction chứa càng ít logic cố định càng tốt cuối cùng 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 bao gồm nguyên trạng, nó sẽ làm giảm độ phức tạp của EVM với chi phí tăng đáng kể độ phức tạp của các phần khác của ngăn xếp Ethereum, yêu cầu mã giống hệt nhau về cơ bản được viết ở nơi khác, ngoại trừ việc giới thiệu các danh mục kỳ lạ hoàn toàn mới, chẳng hạn như cùng một giao dịch với cùng một số 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.
Nhiều vấn đề về vô hiệu hóa trong trừu tượng hóa tài khoản. Một giao dịch được bao gồm trên chuỗi có thể làm mất hiệu lực hàng nghìn giao dịch khác trong mempool, làm cho mempool dễ dàng tràn ngập với giá rẻ.
Kể từ đó, sự trừu tượng hóa tài khoản đã phát triển theo từng giai đoạn. EIP-86 sau đó trở thành EIP-208 và cuối cùng là EIP-2938 thực tế.
Tuy nhiên, EIP-2938 là bất cứ điều gì ngoài tối giản. Nội dung của nó bao gồm:
· Các loại giao dịch mới
· Biến toàn cầu cho ba phạm vi giao dịch mới
· Hai opcode mới, bao gồm opcode PAYgas rất cồng kềnh để xử lý kiểm tra giá gas và giới hạn gas, thực hiện các điểm ngắt dưới dạng EVM và tạm thời lưu trữ ETH với phí một lần
· Một tập hợp phức tạp các chiến lược khai thác và phát sóng lại, bao gồm danh sách các opcode bị cấm trong giai đoạn xác minh giao dịch
Để thực hiện trừu tượng hóa tài khoản mà không liên quan đến 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 các máy khách Ethereum và thực hiện hợp nhất), EIP-2938 cuối cùng đã được kiến trúc lại thành ERC-4337 hoàn toàn ngoài giao thức.
Bởi vì đây là một ERC, 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". Như vậy...... Vấn đề đã được giải quyết chưa? Hóa ra đây không phải là trường hợp. Lộ trình trung hạn hiện tại của ERC-4337 thực sự liên quan đến việc cuối cùng biến phần lớn ERC-4337 thành một tập hợp các tính năng giao thức, đây là một ví dụ hướng dẫn hữu ích về lý do tại sao con đường này nên được xem xét.
** 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 quả khí: Bất kỳ hoạt động nào được thực hiện bên trong EVM đều dẫn đến một số mức chi phí máy ảo, bao gồm cả sự thiếu hiệu quả khi sử dụng các tính năng đắt tiền 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 lên tới ít nhất 20.000 khí hoặc nhiều hơn. Đưa các thành phần này vào một 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 vào lệnh" ERC-4337 có lỗi đủ đáng sợ, tất cả các ví tương thích ERC-4337 có thể thấy tất cả tiền của họ cạn kiệt. Thay thế hợp đồng bằng chức năng trong giao thức tạo ra nghĩa vụ ngầm để sửa lỗi mã thông qua hard fork, do đó loại bỏ nguy cơ tiền của người dùng cạn kiệt.
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 "bundler" đóng gói một tập hợp các hành động của người dùng vào một giao dịch. 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 tế gửi giao dịch, làm cho nó hoạt động giống như EOA.
Chống kiểm duyệt: Một trong những thách thức của việc tách 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. Vấn đề này có thể được giảm bớt đáng kể trong một thế giới nơi giao thức Ethereum có thể nhận ra một giao dịch duy nhất, 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 đóng gói "hoạt động của người dùng" trong một giao dịch duy nhất, làm cho hoạt động của người dùng không rõ ràng với giao thức Ethereum; Do đó, danh sách bao gồm được cung cấp bởi giao thức Ethereum sẽ không thể cung cấp khả năng chống kiểm duyệt cho các hoạt động của người dùng ERC-4337. Đóng gói ERC-4337 và làm cho hành động của người dùng trở thành một loại giao dịch "thích hợp" sẽ giải quyết vấn đề này.
Điều đáng nói là ở dạng hiện tại, ERC-4337 đắt hơn nhiều so với giao dịch Ethereum "cơ bản": chi phí giao dịch là 21.000 gas, trong khi ERC-4337 có giá khoảng 42.000 gas.
Về mặt lý thuyết, có thể điều chỉnh hệ thống chi phí khí EVM cho đến khi chi phí trong thỏa thuận và chi phí truy cập ngoài giao thức để lưu trữ phù hợp; Khi các loại hoạt động chỉnh sửa lưu trữ khác rẻ hơn, không có lý do gì để chuyển ETH ở mức 9000 gas. Trên thực tế, hai EIP liên quan đến việc chuyển đổi cây Verkle sắp tới thực sự cố gắng làm điều đó. Nhưng ngay cả khi chúng ta làm như vậy, có một lý do rõ ràng tại sao chức năng giao thức đóng gói chắc chắn sẽ rẻ hơn nhiều so với mã EVM, bất kể EVM trở nên hiệu quả như thế nào: mã đóng gói không cần phải trả tiền gas để tải trước.
Ví ERC-4337 đầy đủ chức năng rất lớn và việc triển khai biên dịch và đưa nó 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 mỗi ví riêng lẻ gọi nó, nhưng bạn vẫn cần truy cập mã trong mọi khối sử dụng nó. Theo EIP chi phí khí cây Verkle, 12.800 byte sẽ tạo thành 413 khối và việc truy cập các khối này sẽ yêu cầu trả gấp 2 lần chi nhánh nhân chứng \ _cost (tổng cộng 3.800 khí) và 413 lần khối nhân chứng \ _cost (tổng cộng 82.600 khí). Và điều đó thậm chí không bắt đầu đề 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 cây Verkle).
Điều này dẫn đến vấn đề: chi phí gas để thực sự truy cập các mã này bằng cách nào đó phải được khấu hao trên toàn 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 nó đắt hơn nhiều so với các giao dịch khác. Đóng gói trong giao thức sẽ cho phép các thư viện chia sẻ công cộng này là một phần của giao thức và có thể truy cập miễn phí cho tất cả mọi người.
Chúng ta có thể học được gì từ ví dụ này và khi nào bao bì sẽ phổ biến hơn? **
Trong ví dụ này, chúng ta thấy một số lý do khác nhau để đóng gói khía cạnh trừu tượng hóa tài khoản trong 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 ra rì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 có vẻ như mỗi khối có rất nhiều chi phí cố định. 244, 100 gas để tải mã ví tiêu chuẩn là một chuyện; Nhưng tổng hợp có thể thêm hàng trăm ngàn gas vào xác thực ZK-SNARK, cũng như chi phí xác thực bằng chứng chuỗi trên chuỗi. Không có cách nào để tính phí người dùng cho các chi phí này mà không gây ra nhiều sự thiếu hiệu quả của thị trường và việc dịch 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 đều có thể truy cập miễn phí sẽ giải quyết tốt vấn đề này.
Phản hồi trên toàn cộng đồng đối với lỗi mã. Nếu một số đoạn mã đượ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, cộng đồng blockchain thường có ý nghĩa hơn khi chịu trách nhiệm về một hard fork để sửa bất kỳ lỗi nào phát sinh. ERC-4337 giới thiệu một lượng lớn mã được chia sẻ trên toàn cầu và việc sửa lỗi trong mã thông qua hard fork chắc chắn sẽ hợp lý hơn về lâu dài so với việc khiến người dùng mất nhiều ETH.
Đôi khi, một hình thức mạnh mẽ hơn có thể đạt được bằng cách tận dụng trực tiếp chức năng của giao thức. Ví dụ chính ở đây là 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 phương pháp bên ngoài giao thức và để các hoạt động cấp người dùng thực sự được hưởng lợi từ danh sách bao gồm trong giao thức, một hoạt động cấp người dùng duy nhất cần phải "có thể đọc được" đối với giao thức. 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 2017 đã trừu tượng hóa tài khoản khóa cổ phần, đã bị bỏ rơi để ủng hộ việc đóng gói BLS, vì BLS hỗ trợ cơ chế "tổng hợp" phải được triển khai ở cấp độ giao thức và mạng, có thể giúp 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 trừu tượng hóa tài khoản trong giao thức vẫn là một sự "đóng gói" rất lớn so với tình hình hiện tại. Ngày nay, các giao dịch Ethereum hàng đầu 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 một chữ ký đường cong elip 256k1 secp duy nhất. Trừu tượng hóa tài khoản loại bỏ điều này và để lại các tiêu chí xác thực cho người dùng xác định. Vì vậy, trong câu chuyện về trừu tượng hóa tài khoản này, chúng ta cũng thấy lập luận lớn nhất chống lại việc đóng gói: tính linh hoạt để đáp ứng nhu cầu của những người dùng khác nhau.
Hãy làm rõ câu chuyện này hơn nữa 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 coi là gói gọn. Chúng tôi sẽ đặc biệt chú ý đến: ZK-EVM, tách người đề xuất-người xây dựng, mempool riêng, đặt cọc thanh khoản và biên dịch trước.
Gói 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 của giao thức Ethereum: ZK-EVM. Hiện tại, chúng tôi có một số lượng lớn ZK-rollups, 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à nhiều hơn nữa.
Một cuộc tranh cãi gần đây trong không gian EVM ZK-rollup liên quan đến cách xử lý các lỗi có thể xảy ra trong mã ZK. Hiện tại, tất cả các hệ thống đang chạy 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 để khuyến khích các dự án làm rõ mức độ tin cậy của họ vào hệ thống chứng nhận, cũng như trong Hội đồng Bảo an, và giảm dần thẩm quyền của họ đối với tổ chức theo thời gian.
Trong trung hạn, các bản tổng hợp có thể dựa vào nhiều hệ thống chứng thực và Hội đồng Bảo an sẽ chỉ có quyền lực trong những trường hợp cực đoan khi hai hệ thống chứng thực khác nhau khác nhau.
Tuy nhiên, có cảm giác rằng một số công việc cảm thấy 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ý lỗi trong quá trình triển khai: nếu có lỗi, máy khách sẽ cập nhật để sửa lỗi và sau đó chuỗi sẽ tiếp tục hoạt động. Từ quan điểm của khách hàng lỗi, có vẻ như các khối đã được hoàn thiện sẽ không còn được xác nhận, nhưng ít nhất chúng ta sẽ không thấy người dùng mất tiền. Tương tự, nếu các bản tổng hợp chỉ muốn duy trì vai trò tương đương với EVM, thì họ cần thực hiện 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 họ để phù hợp với việc nâng cấp lên lớp cơ sở Ethereum, điều này cảm thấy sai vì cuối cùng chúng được xây dựng trên chính lớp cơ sở Ethereum, biết khi nào cần nâng cấp và theo quy tắc mới nào.
Vì các L2 ZK-EVM này về cơ bản sử dụng chính xác các EVM giống như Ethereum, chúng ta có thể bằng cách nào đó 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 ngoại lệ như lỗi và nâng cấp bằng cách áp dụng sự đồng thuận xã hội của Ethereum, như chúng ta đã làm với chính việc triển khai EVM lớp cơ sở không?
Đây là một chủ đề quan trọng và đầy thách thức.
Một chủ đề có thể tranh luận về tính khả dụng của dữ liệu trong ZK-EVM gốc là tính trạng thái. Nếu ZK-EVM không cần mang dữ liệu "nhân chứng", hiệu quả dữ liệu của chúng sẽ cao hơn nhiều. Đó 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ể chỉ cần giả định rằng người chứng minh có quyền truy cập vào nó và không phải cung cấp lại. Nó không chỉ là về việc không tải lại bộ nhớ và mã; Nó chỉ ra rằng nén trạng thái có thể tiết kiệm tới 3x dữ liệu so với nén không trạng thái nếu một bản tổng hợp nén dữ liệu một cách chính xác.
Điều này có nghĩa là đối với biên dịch trước ZK-EVM, chúng tôi có hai tùy chọn:
Việc 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 đoạn. Điều này có nghĩa là prover có thể không có trạng thái, nhưng nó cũng có nghĩa là sử dụng ZK-rollup được biên dịch sẵn này đắt hơn nhiều so với sử dụng rollup với mã tùy chỉnh.
Biên dịch trước cho phép con trỏ trỏ đến dữ liệu đã được thực thi, sử dụng hoặc tạo trước đó. Điều này làm cho ZK-rollup gần như tối ưu, nhưng nó phức tạp hơn và giới thiệu một trạng thái mới phải được lưu trữ bởi prover.
Chúng ta có thể học được gì từ điều này? Có một lý do chính đáng để bằng cách nào đó gói gọn xác minh ZK-EVM: 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 cân nhắc nhiều triển khai và sự đồng thuận xã hội ngoài chuỗi của nó trên L1 để thực thi EVM, điều này cảm thấy sai, nhưng L2 làm chính xác cùng một công việc phải thực hiện các 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 vấn đề lớn trong các chi tiết: có nhiều phiên bản khác nhau của ZK-EVM, khác nhau về chi phí và lợi ích. Sự phân biệt giữa trạng thái và không quốc tịch chỉ làm trầy xước bề mặt; Cố gắng hỗ trợ "gần như EVM", mã tùy chỉnh đã được chứng minh bởi các hệ thống khác, có thể phơi bày nhiều không gian thiết kế hơn. Do đó, việc đóng gói ZK-EVM mang lại cả hứa hẹn và thách thức.
** Wrapper và Builder Separation (ePBS) **
Sự gia tăng của MEV đã làm cho sản xuất khối trở thành một hoạt động kinh tế quy mô lớn, với những người tham gia phức tạp 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, chỉ đơn giản là quan sát mempool của các 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 sơ đồ tách biệt người đề xuất-người xây dựng ngoài giao thức như MEV-Boost, cho phép người xác nhận thông thường ("người đề xuất") thuê ngoài xây dựng khối cho những người tham gia chuyên biệt ("nhà xây dựng").
Tuy nhiên, MEV-Boost đưa ra các giả định tin tưởng vào một lớp người tham gia mới được gọi là rơle. Trong hai năm qua, đã có nhiều đề xuất để tạo ra "PBS đóng 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: PBS được xây dựng trực tiếp với các tính năng giao thức mạnh hơn (theo nghĩa là có các giả định tin cậy yếu hơn) so với PBS được xây dựng mà không có chúng. Điều này tương tự như trường hợp của các nhà tiên tri giá trong giao thức đóng gói - mặc dù trong trường hợp này, cũng có sự 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ó 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 của nhiều ứng dụng dễ bị tấn công kinh tế, chẳng hạn như giao dịch phủ đầu.
Gần đây, đã có một số dự án dành riêng cho việc tạo ra "mempool riêng tư" (hoặc "mempool được mã hóa") mã hóa các giao dịch của người dùng cho đến khi chúng được chấp nhận không thể đảo ngược vào một khối.
Tuy nhiên, vấn đề là các chương trình như vậy đòi hỏi một loại mã hóa đặc biệt: để ngăn người dùng tràn ngập hệ thống và giải mã nó trước, mã hóa phải được tự động giải mã sau khi giao dịch thực sự được chấp nhận không thể đảo ngược.
Để đạt được hình thức mã hóa này, có nhiều kỹ thuật đánh đổi khác nhau. Jon Charbonneau đã từng nói rất hay:
Mã hóa các toán tử tập trung, chẳng hạn như Flashbots Protect.
mã hóa khóa thời gian, có thể được giải mã bởi bất kỳ ai sau một bước tính toán tuần tự nhất định và không thể song song;
Mã hóa ngưỡng, tin tưởng một ủy ban đa số trung thực để giải mã dữ liệu. Để biết các khuyến nghị cụ thể, hãy xem Khái niệm chuỗi đèn hiệu đóng.
Phần cứng đáng tin cậy, chẳng hạn như SGX.
Thật không may, mỗi mã hóa có những điểm yếu khác nhau. Mặc dù đối với mọi giải pháp, có một tập hợp con người dùng sẵn sàng tin tưởng nó, nhưng không có giải pháp nào đủ tin cậy để nó thực sự được Lớp 1 chấp nhận. Vì vậy, ít nhất là cho đến khi mã hóa độ trễ đượ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 giao dịch chống nâng cao ở Lớp 1 có vẻ 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 **
Một nhu cầu phổ biến đối với người dùng Ethereum DeFi là khả năng sử dụng ETH của họ đồng thời để đặt cọc và làm tài sản thế chấp trong các ứng dụng khác. Một nhu 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 sự phức tạp của việc chạy một nút và giữ cho 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à 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 đã bắt đầu làm như vậy. Tuy nhiên, đặt cọc thanh khoản có một số cơ chế tập trung tự nhiên trong công việc: mọi người tự nhiên chuyển sang phiên bản đặt cọc ETH lớn nhất vì nó quen thuộc và thanh khoản nhất.
Mỗi phiên bản đặt cọc ETH yêu cầu một số cơ chế để xác định ai có thể là nhà điều hành nút cơ bản. Nó không thể là không giới hạn, vì sau đó những kẻ tấn công sẽ tham gia và khuếch đại cuộc tấn công bằng tiền của người dùng. Hiện tại, hai công ty hàng đầu là Lido, có nhà điều hành nút danh sách trắng DAO và Rocket Pool, cho phép bất kỳ ai chạy một nút có 8 ETH được gửi. Hai phương pháp có rủi ro khác nhau: cách tiếp cận Rocket Pool cho phép kẻ tấn công thực hiện các cuộc tấn công 51% vào mạng và buộc người dùng phải trả phần lớn chi phí; Đối với cách tiếp cận DAO, nếu một mã thông báo đặt cọc nhất định chiếm ưu thế, nó sẽ dẫn đến một tiện ích quản trị duy nhất, có khả năng bị tấn công kiểm soát một phần đáng kể của tất cả các trình xác thực Ethereum. Để chắc chắn, các giao thức như Lido đã có các biện pháp phòng ngừa, nhưng một lớp phòng thủ có thể 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 đặt cọc thanh khoản đa dạng để giảm khả năng rủi ro hệ thống từ một công ty duy nhất. Tuy nhiên, về lâu dài, đây là một trạng thái cân bằng bấp bênh, và thật nguy hiểm khi dựa quá nhiều vào áp lực đạo đức để giải quyết vấn đề. Một câu hỏi tự nhiên được đặt ra: liệu có hợp lý khi đóng gói một số loại chức năng trong giao thức để làm cho việc đặt cọc thanh khoản ít tập trung hơn không?
Câu hỏi chính ở đây là: loại chức năng trong giao thức nào? Vấn đề với việc chỉ đơn giản là tạo ra một mã thông báo "đặt cọc ETH" có thể thay thế trong giao thức là nó phải có quản trị toàn Ethereum được đóng gói để chọn người chạy các nút hoặc nó đang mở, nhưng điều này biến nó thành một công cụ cho những kẻ tấn công.
Một ý tưởng thú vị là bài viết của Dankrad Feist về tối đa hóa đặt cọc thanh khoản. Đầu tiên, hãy cắn viên đạn và nếu Ethereum bị tấn công bởi 51%, chỉ có 5% ETH tấn công có thể bị tịch thu. Đâ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, một phần ba trong số đó (khoảng 8 triệu ETH) chi phí tấn công là quá mức, đặc biệt là 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 với chi phí thấp hơn. Trên thực tế, sự đánh đổi tương tự đã được khám phá trong đề xuất của Super Commission để thực hiện tính cuối cùng của một vị trí.
Nếu chúng tôi chấp nhận rằng chỉ có 5% ETH tấn công bị tịch thu, thì hơn 90% ETH được đặt cọc sẽ không bị ảnh hưởng bởi việc tịch thu, vì vậy chúng có thể được sử dụng làm mã thông báo đặt cọc thanh khoản có thể thay thế trong giao thức và sau đó được sử dụng bởi các ứng dụng khác.
Con đường thật thú vị. Nhưng nó vẫn để lại câu hỏi: chính xác những gì được gói gọn? Rocket Pool hoạt động rất giống nhau: mỗi nhà khai thác nút cung cấp một số tiền và người đặt cọc thanh khoản 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 mức phạt tối đa là 2 ETH và rETH hiện có của Rocket Pool sẽ trở nên 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 những việc thông minh khác. Ví dụ: giả sử chúng ta muốn một hệ thống có hai "lớp" đặt cược: nhà khai thác 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 và 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 ngăn chặn sự tập trung của các nhà khai thác nút bằng cách trao quyền cho một ủy ban người gửi tiền được lấy mẫu ngẫu nhiên, 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 ngã ba trong thời gian rò rỉ không hoạt động hoặc yêu cầu ký khối. Điều này có thể đạt được theo cách về cơ bản tách ra khỏi giao thức bằng cách tinh 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 gọi trên mỗi khe để xuất khóa đặt cọc thứ cấp. Giao thức sẽ cung cấp năng lượng cho cả hai khóa, nhưng cơ chế chọn khóa thứ hai trong mỗi khe có thể được để lại cho giao thức nhóm đặt cọc. Vẫn có thể tốt hơn để đóng gói trực tiếp một số tính năng, nhưng điều đáng chú ý là không gian thiết kế "bao gồm một số thứ và để lại mọi thứ khác cho người dùng" tồn tại.
** Đóng gói thêm các bản tổng hợp trước **
Biên dịch sẵn (hoặc "hợp đồng biên dịch trước") là các hợp đồng Ethereum thực hiện các hoạt động mật mã phức tạp, 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 sự thỏa hiệp được thông qua khi bắt đầu phát triển Ethereum: vì chi phí của một máy ảo quá lớn đối với một số mã rất phức tạp và chuyên dụng cao, chúng tôi có thể thực hiện một số hoạt động chính trong mã cục bộ có giá trị đối với các ứng dụng quan trọng để làm cho nó nhanh hơn. Ngày nay, điều này về cơ bản bao gồm một số hàm băm cụ thể và các phép toán đường cong elip.
Hiện tại có một sự thúc đẩy để thêm precompilation cho secp 256 R1, một đường cong elip hơi khác so với secp 256 K1 cho các tài khoản Ethereum cơ bản, vì nó được hỗ trợ tốt bởi các mô-đun phần cứng đáng tin cậy, vì vậy việc sử dụng rộng rãi nó có thể cải thiện bảo mật ví. Trong những năm gần đây, cộng đồng cũng đã thúc đẩy việc bổ sung các bản 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.
Đối lập với những yêu cầu này đối với các tệp được biên dịch sẵn hơn là nhiều bản biên dịch trước được thêm vào trước đó (ví dụ: RIPEMD và BLAKE) cuối cùng sử dụng ít hơn nhiều so với dự kiến và chúng ta nên học hỏi từ chúng. Thay vì thêm nhiều 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 một cách tiếp cận nhẹ nhàng hơn dựa trên các ý tưởng như EVM-MAX và các đề xuất SIMD không hoạt động nhưng luôn có thể phục hồi, điều này sẽ cho phép triển khai EVM thực thi một loạt các lớp mã với chi phí thấp hơn. Có lẽ ngay cả việc biên dịch trước hiếm khi được sử dụng hiện có cũng có thể bị loại bỏ và thay thế bằng việc triển khai (chắc chắn kém hiệu quả hơn) mã EVM của cùng một chức năng. Điều đó nói rằng, vẫn có thể có các hoạt động mật mã cụ thể đủ giá trị để tăng tốc, vì vậy thật hợp lý khi thêm chúng dưới dạng biên dịch sẵn.
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ó xuất phát 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 nghi với các nhu cầu khác nhau của người dùng và tránh lời nguyền của phần mềm phình to. Tuy nhiên, blockchain không phải là một 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à nó có ý nghĩa để đóng gói một số chức năng nhất định trong giao thức.
Trong nhiều trường hợp, các ví dụ khác này tương tự như những gì chúng ta thấy trong bả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:
Đóng gói có thể giúp tránh nguy cơ tập trung hóa ở những nơi khác trong ngăn xếp:
Thông thường, việc giữ cho giao thức cơ bản tối thiểu và đơn giản sẽ đẩy sự phức tạp vượt ra ngoài một số giao thức của hệ sinh thái. Từ quan điểm triết học Unix, điều này là tốt. Tuy nhiên, đôi khi có rủi ro là các hệ sinh thái ngoài giao thức sẽ tập trung, thường (nhưng không chỉ) vì 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ế.
Đóng gói quá nhiều nội dung có thể mở rộng quá mức gánh nặng tin cậy và quản trị trên giao thức:
Đây là chủ đề của một bài viết trước về "Đừng làm quá tải sự đồng thuận của Ethereum": nếu việc đóng gói một chức năng cụ thể làm suy yếu mô hình tin cậy và làm cho Ethereum nói chung trở nên "chủ quan" hơn, nó sẽ làm suy yếu tính trung lập đáng tin cậy của Ethereum. Trong những trường hợp này, tốt hơn là trình bày một tính năng cụ thể như một cơ chế trên Ethereum hơn là cố gắng giới thiệu nó với chính Ethereum. Ở đây, các nhóm bộ nhớ được mã hóa là ví dụ tốt nhất và có thể hơi khó đóng gói, ít nhất là cho đến khi mã hóa độ trễ được cải thiện.
Đóng gói quá nhiều có thể làm phức tạp quá mức giao thức:
Độ phức tạp của giao thức là một rủi ro hệ thống có thể tăng lên bằng cách thêm quá nhiều tính năng vào giao thức. Precompilation là ví dụ tốt nhất.
Về lâu dài, chức năng đóng gói có thể phản tác dụng vì nhu cầu của người dùng 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ó thể không được sử dụng thường xuyên trong thực tế.
Ngoài ra, việc đặt cọc thanh khoản, ZK-EVM và các trường hợp được biên dịch trước cho thấy khả năng của một con đường trung gian: sự tôn thờ khả thi tối thiểu. Các giao thức không cần phải gói gọn toàn bộ chức năng, nhưng có thể chứa các phần cụ thể giải quyết các thách thức chính, làm cho chức năng dễ thực hiện mà không quá hoang tưởng hoặc quá hẹp. Ví dụ về điều này bao gồm:
Thay vì gói gọn một hệ thống cầm cố thanh khoản hoàn chỉnh, tốt hơn là thay đổi các quy tắc phạt đặt cọc để làm cho việc cầm cố thanh khoản không tin cậy trở nên khả thi hơn;
Thay vì đóng gói nhiều trình biên dịch trước, hãy đóng gói EVM-MAX và / hoặc SIMD để giúp dễ dàng triển khai hiệu quả hơn cho nhiều danh mục hoạt động hơn;
Xác minh EVM có thể được đóng gói đơn giản thay vì gói gọn toàn bộ khái niệm tổng hợp.
Chúng ta có thể mở rộng biểu đồ trước đó như sau:
Đôi khi nó có ý nghĩa để bọc một cái gì đó, và loại bỏ precompilation hiếm khi được sử dụng là một ví dụ. 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 đó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ế thực sự có thể tương tự như cơ chế đóng gói sẵn: một trong những đề xuất là EIP-5003, cho phép EOA chuyển đổi tài khoản của mình thành hợp đồng có cùng chức năng (hoặc tốt hơn).
Những tính năng nào nên được đưa vào giao thức và 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 và các ý tưởng và bộ công nghệ có sẵn tiếp tục được cải thiện.