Vitalik: Tương lai của giao thức Ethereum – The Splurge

Tác giả: Vitalik, người sáng lập Ethereum; Người biên soạn: Deng Tong, Golden Finance

Lưu ý: Bài viết này là bài thứ sáu trong loạt bài viết về "Sự phát triển trong tương lai của Giao thức Ethereum" được xuất bản gần đây bởi Vitalik, người sáng lập Ethereum Phần "Tương lai có thể có của giao thức Ethereum, phần 6: The Splurge", để biết phần thứ năm, hãy xem " Vitalik: Tương lai có thể có của giao thức Ethereum—The Purge", phần 4 có thể được tìm thấy tại "Vitalik: Tương lai của Ethereum The Verge”. Bạn có thể tìm thấy phần thứ ba trong "Vitalik: Mục tiêu chính của Giai đoạn tai họa của Ethereum", và phần thứ hai có thể có thể tìm thấy trong "Vitalik: Giao thức Ethereum nên phát triển như thế nào trong The Surge", hãy xem phần đầu tiên trong "< a href="https:// www.jinse.cn/blockchain/3699549.html">Những điều gì khác có thể được cải thiện trong Ethereum PoS". Dưới đây là toàn văn Phần 6:

Đặc biệt cảm ơn Justin Drake và Tim Beiko vì những phản hồi và nhận xét của họ.

Có một số thứ rất khó để xếp vào một danh mục. Có rất nhiều “điều nhỏ nhặt” trong thiết kế giao thức Ethereum rất có giá trị đối với sự thành công của Ethereum nhưng không phù hợp với các danh mục con lớn hơn. Trên thực tế, khoảng một nửa trong số chúng có liên quan đến các cải tiến EVM khác nhau, phần còn lại bao gồm các chủ đề thích hợp khác nhau. Đó chính là mục đích của "Splurge".

Splurge, Lộ trình năm 2023

The Splurge: Mục tiêu chính

• Đưa EVM đến "trạng thái cuối cùng" về hiệu suất cao và độ ổn định

• Đưa tính năng trừu tượng hóa tài khoản vào giao thức để tất cả người dùng có thể hưởng lợi từ các tài khoản an toàn và thuận tiện hơn

• Tối ưu hóa tính kinh tế của phí giao dịch và cải thiện khả năng mở rộng đồng thời giảm rủi ro

• Khám phá mật mã nâng cao có thể giúp Ethereum tốt hơn trong thế giới dài hạn

Cải tiến EVM

Nó giải quyết được Vấn đề là gì?

EVM ngày nay khó phân tích tĩnh, gây khó khăn cho việc triển khai hiệu quả, xác minh chính thức mã và mở rộng mã theo thời gian. Ngoài ra, nó rất kém hiệu quả, gây khó khăn cho việc triển khai nhiều dạng mật mã nâng cao trừ khi chúng được hỗ trợ rõ ràng thông qua quá trình biên dịch trước.

Nó là gì và hoạt động như thế nào?

Bước đầu tiên trong lộ trình cải tiến EVM hiện tại là Định dạng đối tượng EVM (EOF), dự kiến ​​sẽ được đưa vào đợt hard fork tiếp theo. EOF là một chuỗi EIP chỉ định phiên bản mới của mã EVM với một số tính năng độc đáo, đáng chú ý nhất là:

• Sự tách biệt giữa mã (có thể thực thi nhưng không thể đọc được từ EVM) và dữ liệu (có thể đọc được nhưng không thể thực thi được).

• Các bước nhảy động bị cấm và chỉ cho phép các bước nhảy tĩnh.

• Mã EVM không thể quan sát thông tin liên quan đến khí đốt nữa.

• Đã thêm cơ chế chương trình con rõ ràng mới.

Cấu trúc mã EOF

Hợp đồng kiểu cũ sẽ tiếp tục tồn tại và có thể được tạo, mặc dù các hợp đồng cũ cuối cùng có thể không còn được dùng nữa (và thậm chí có thể bị buộc phải chuyển đổi sang mã EOF). Các hợp đồng kiểu mới hơn sẽ được hưởng lợi từ những cải tiến hiệu quả do EOF mang lại - đầu tiên, các mã byte nhỏ hơn một chút để tận dụng các chức năng chương trình con, sau đó là các chức năng mới dành riêng cho EOF hoặc chi phí gas dành riêng cho EOF sẽ giảm.

Với việc giới thiệu EOF, việc giới thiệu các bản nâng cấp tiếp theo sẽ trở nên dễ dàng hơn. Hoàn thiện nhất hiện nay là Phần mở rộng số học mô-đun EVM (EVM-MAX). EVM-MAX tạo ra một tập hợp các phép toán mới được thiết kế cho số học mô-đun và đặt chúng vào một không gian bộ nhớ mới mà các opcode khác không thể truy cập được. Điều này cho phép sử dụng các phép tối ưu hóa như phép nhân Montgomery.

Một ý tưởng mới hơn là kết hợp EVM-MAX với khả năng đa dữ liệu lệnh đơn (SIMD). SIMD đã là một ý tưởng trong Ethereum kể từ EIP-616 của Greg Colvin. SIMD có thể được sử dụng để tăng tốc nhiều hình thức mã hóa, bao gồm hàm băm, STARK 32 bit và mã hóa dựa trên mạng. EVM-MAX và SIMD cùng nhau tạo thành một cặp tiện ích mở rộng hướng đến hiệu suất cho EVM.

Thiết kế gần đúng của EIP kết hợp dựa trên EIP-6690 làm điểm bắt đầu, sau đó:

• Cho phép (i) bất kỳ số lẻ nào hoặc (ii) bất kỳ lũy thừa nào của 2 (tối đa 2^768) làm mô đun

• Đối với mỗi opcode EVMMAX ( add, sub, mul), hãy thêm một phiên bản thay vì lấy 3 số liền kề x, y, z, lấy 7 số liền kề: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Trong mã Python, các opcode này sẽ hoạt động tương đương với:

Ngoại trừ việc triển khai thực tế, nó sẽ được xử lý song song.

• Nếu có thể, hãy thêm XOR, AND, OR modulo ít nhất là lũy thừa 2 , KHÔNG và SHIFT (theo chu kỳ và không theo chu kỳ). Đồng thời thêm ISZERO (đẩy đầu ra vào ngăn xếp chính EVM).

Điều này sẽ đủ mạnh để triển khai mật mã đường cong elip, mật mã miền nhỏ (như Poseidon, STARK tròn), các hàm băm truyền thống (như SHA256, KECCAK, BLAKE) và mật mã dựa trên mạng.

Có thể nâng cấp EVM khác nhưng cho đến nay chúng ít được chú ý hơn.

Có những nghiên cứu nào hiện có?

EOF: https:// evmobjectformat.org/

EVM-MAX:https://eips.ethereum.org/EIPS/eip-6690

SIMD: https ://eips.ethereum.org/EIPS/eip-616

Những gì còn lại phải làm và sự đánh đổi là gì?

Hiện tại, EOF dự kiến ​​sẽ được đưa vào đợt hard fork tiếp theo. Mặc dù luôn có thể loại bỏ nó - các tính năng trong các đợt hard fork trước đó đã bị xóa vào phút cuối - nhưng làm như vậy sẽ là một cuộc chiến khó khăn. Loại bỏ EOF có nghĩa là mọi nâng cấp trong tương lai lên EVM sẽ không thể sử dụng EOF, điều này có thể thực hiện được nhưng có thể khó khăn hơn.

Sự đánh đổi chính với EVM là độ phức tạp L1 so với độ phức tạp của cơ sở hạ tầng. EOF là một lượng lớn mã được thêm vào quá trình triển khai EVM và việc kiểm tra mã tĩnh rất phức tạp. Tuy nhiên, đổi lại, chúng tôi đạt được sự đơn giản hóa ngôn ngữ cấp cao, đơn giản hóa việc triển khai EVM và các lợi ích khác. Đủ để nói, một lộ trình ưu tiên cải tiến liên tục cho Ethereum L1 sẽ bao gồm và xây dựng trên EOF.

Một phần công việc quan trọng là triển khai một số thứ như EVM-MAX cộng với SIMD và đánh giá lượng gas mà các hoạt động mã hóa khác nhau yêu cầu.

Nó tương tác với các phần khác của lộ trình như thế nào?

L1 điều chỉnh EVM của mình để giúp L2 thực hiện điều tương tự dễ dàng hơn. Việc điều chỉnh cái này với cái kia sẽ tạo ra một số điểm không tương thích, điều này có những nhược điểm riêng. Ngoài ra, EVM-MAX kết hợp với SIMD có thể giảm chi phí gas của nhiều hệ thống thử nghiệm, cho phép tạo ra L2 hiệu quả hơn. Nó cũng giúp loại bỏ nhiều phần biên dịch trước dễ dàng hơn bằng cách thay thế chúng bằng mã EVM có thể thực hiện cùng một tác vụ mà không ảnh hưởng lớn đến hiệu quả.

Sự trừu tượng hóa tài khoản

Nó giải quyết được vấn đề gì?

Hiện tại, các giao dịch chỉ có thể được xác minh bằng một cách: chữ ký ECDSA. Ban đầu, việc trừu tượng hóa tài khoản nhằm mục đích vượt xa điều này và cho phép logic xác thực của tài khoản trở thành mã EVM tùy ý. Điều này cho phép nhiều ứng dụng:

• Chuyển sang mã hóa kháng lượng tử; p>

• Xoay vòng khóa cũ (được coi là một biện pháp bảo mật được khuyến nghị rộng rãi);

• Ví đa chữ ký và ví phục hồi xã hội ;< /p>

• Sử dụng một khóa để ký các hoạt động có giá trị thấp và một khóa khác (hoặc bộ khóa) để ký các hoạt động có giá trị cao;

  < /li>
• < p>Cho phép các giao thức bảo mật hoạt động mà không cần chuyển tiếp, giảm đáng kể độ phức tạp của chúng và loại bỏ các điểm phụ thuộc trung tâm chính.

Kể từ khi bắt đầu trừu tượng hóa tài khoản vào năm 2015, các mục tiêu đã mở rộng để bao gồm một số lượng lớn "mục tiêu tiện lợi", chẳng hạn như các tài khoản không có ETH nhưng một số ERC20 có thể để trả tiền xăng bằng ERC20 đó. Bản tóm tắt về những mục tiêu này được hiển thị trong bảng bên dưới:

MPC ở đây là tính toán của nhiều bên: một công nghệ 40 năm tuổi chia khóa thành nhiều phần, lưu trữ chúng trên nhiều thiết bị và sử dụng mật mã để tạo chữ ký mà không cần kết hợp trực tiếp nhiều phần khác nhau của khóa.

EIP-7702 là EIP dự kiến ​​sẽ được giới thiệu trong đợt hard fork tiếp theo. EIP-7702 là kết quả của sự nhận thức ngày càng tăng về nhu cầu cung cấp sự tiện lợi trong việc trừu tượng hóa tài khoản cho tất cả người dùng, bao gồm cả người dùng EOA, để cải thiện trải nghiệm người dùng của mọi người trong thời gian ngắn và tránh chia tách thành hai hệ sinh thái. Công việc này bắt đầu ở EIP-3074 và lên đến đỉnh điểm ở EIP-7702. EIP-7702 cung cấp "tính năng tiện lợi" của việc trừu tượng hóa tài khoản cho tất cả người dùng, bao gồm cả EOA (tài khoản thuộc sở hữu bên ngoài, tức là các tài khoản được kiểm soát bởi chữ ký ECDSA).

Chúng ta có thể thấy từ biểu đồ rằng mặc dù một số thách thức (đặc biệt là thách thức "tiện lợi") có thể được giải quyết bằng tính toán của nhiều bên hoặc các công nghệ tiến bộ như EIP-7702, nhưng hầu hết các đề xuất trừu tượng hóa tài khoản ban đầu đều được thực hiện Các mục tiêu Bảo mật được đề xuất chỉ có thể được giải quyết bằng cách quay lại vấn đề ban đầu: cho phép mã hợp đồng thông minh kiểm soát việc xác minh giao dịch. Lý do điều này vẫn chưa được thực hiện cho đến nay là vì việc triển khai nó một cách an toàn là một thách thức.

Nó là gì vậy? Nó hoạt động như thế nào?

Về cốt lõi, việc trừu tượng hóa tài khoản rất đơn giản: cho phép các giao dịch được bắt đầu thông qua hợp đồng thông minh (không chỉ EOA). Toàn bộ sự phức tạp xuất phát từ việc thực hiện việc này theo cách có lợi cho việc duy trì mạng lưới phi tập trung và ngăn chặn các cuộc tấn công từ chối dịch vụ.

Một ví dụ minh họa cho thách thức chính là vấn đề đa vô hiệu:

ERC-4337 Cách thức hoạt động là việc xử lý các thao tác của người dùng được chia thành hai giai đoạn: xác minh và thực thi. Tất cả các xác nhận được xử lý trước tiên, sau đó là tất cả các lần thực thi. Trong mempool, hành động của người dùng chỉ được chấp nhận nếu giai đoạn xác thực hành động của người dùng chỉ chạm vào tài khoản của chính họ và không đọc các biến môi trường. Điều này ngăn chặn nhiều cuộc tấn công null. Bước xác minh cũng thực thi các giới hạn gas nghiêm ngặt.

ERC-4337 được thiết kế như một tiêu chuẩn ngoài giao thức (ERC) vì tại thời điểm đó, các nhà phát triển ứng dụng khách Ethereum tập trung vào việc hợp nhất và không có khả năng dự phòng để xử lý các tính năng khác. Đây là lý do tại sao ERC-4337 sử dụng các đối tượng riêng của nó được gọi là hành động của người dùng thay vì các giao dịch thông thường. Tuy nhiên, gần đây, chúng tôi nhận thấy cần phải kết hợp ít nhất một phần điều này vào giao thức. Hai lý do chính là:

• Sự kém hiệu quả vốn có của EntryPoint như một hợp đồng: mỗi lý do Đã sửa lỗi ~100 nghìn chi phí gas cho các gói và hàng nghìn khoản phí bổ sung cho mỗi hoạt động của người dùng;

• Bắt buộc để đảm bảo các thuộc tính Ethereum (chẳng hạn như đảm bảo bao gồm được tạo bởi danh sách bao gồm) được chuyển sang tài khoản Người dùng trừu tượng .

Ngoài ra, ERC-4337 còn mở rộng hai chức năng:

• Người thanh toán: Một tính năng cho phép một tài khoản thanh toán thay mặt cho một tài khoản khác. Điều này vi phạm quy tắc chỉ có thể truy cập vào tài khoản người gửi trong giai đoạn xác minh, do đó, xử lý đặc biệt đã được đưa ra để cho phép cơ chế thanh toán và đảm bảo tính bảo mật của nó.

• Bộ tổng hợp: Một tính năng hỗ trợ tập hợp chữ ký, chẳng hạn như tập hợp BLS hoặc tập hợp dựa trên SNARK. Điều này là cần thiết để đạt được hiệu quả dữ liệu tối đa khi tổng hợp.

Có những nghiên cứu nào hiện có?

Giới thiệu lịch sử tóm tắt tài khoản: https://www.youtube.com/watch?v=iLf8qpOmxQc

ERC -4337: https://eips. ethereum.org/EIPS/eip-4337

EIP-7702: https://eips.ethereum.org/EIPS/eip-7702

Mã BLSWallet (sử dụng chức năng tổng hợp): https://github.com/getwax/bls-wallet

EIP-7562 (trừu tượng tài khoản nhúng):< a href="https://eips.ethereum.org/EIPS/eip-7562" _src="https://eips.ethereum.org/EIPS/eip-7562">https://eips.ethereum.org/ EIPS/eip-7562

EIP-7701 (AA nhúng dựa trên EOF): https://eips.ethereum.org/EIPS/eip-7701

Những việc còn lại phải làm là gì, và sự đánh đổi là gì?

Câu hỏi chính còn lại là làm thế nào để kết hợp đầy đủ tính năng trừu tượng hóa tài khoản vào giao thức. EIP trừu tượng hóa tài khoản phổ biến nhất gần đây là EIP-7701, triển khai tính năng trừu tượng hóa tài khoản trên EOF. Tài khoản có thể có phần mã riêng để xác minh và nếu tài khoản có thiết lập phần mã này thì mã sẽ được thực thi trong bước xác minh giao dịch của tài khoản.

< span style="font-size: 14px;">Cấu trúc mã EOF của tài khoản EIP-7701

Điều thú vị về phương pháp này là nó thể hiện rõ ràng hai cách tương đương để xem sự trừu tượng hóa tài khoản gốc :

• EIP-4337, nhưng là Phần giao thức

• Một loại EOA mới trong đó thuật toán chữ ký là thực thi mã EVM

Nếu trước tiên chúng tôi giới hạn nghiêm ngặt thời gian xác minh. Độ phức tạp của mã thực thi - không cho phép truy cập trạng thái bên ngoài hoặc thậm chí đặt giới hạn gas quá thấp để không hữu ích cho các ứng dụng chống lượng tử hoặc bảo vệ quyền riêng tư ngay từ đầu - thì tính bảo mật của phương pháp này là rất rõ ràng: Nó chỉ đơn giản thay thế xác minh ECDSA bằng EVM thực thi mã mất thời gian tương tự. Tuy nhiên, theo thời gian, chúng ta sẽ cần phải nới lỏng những hạn chế này, vì việc cho phép các ứng dụng bảo vệ quyền riêng tư hoạt động mà không cần bộ lặp cũng như khả năng kháng lượng tử đều quan trọng. Để làm được điều này, chúng ta thực sự cần tìm cách giải quyết rủi ro DoS một cách linh hoạt hơn mà không yêu cầu bước xác minh cực kỳ đơn giản.

Sự đánh đổi chính dường như là "chấp nhận thứ gì đó làm hài lòng ít người càng nhanh càng tốt" thay vì "chờ đợi lâu hơn và có thể có được giải pháp lý tưởng hơn". Cách tiếp cận lý tưởng có thể là một số cách tiếp cận kết hợp. Một cách tiếp cận kết hợp là lưu giữ một số trường hợp sử dụng nhanh hơn và cho phép có nhiều thời gian hơn để giải quyết những trường hợp khác. Một cách tiếp cận khác là trước tiên hãy triển khai một phiên bản trừu tượng hóa tài khoản đầy tham vọng hơn trên L2. Tuy nhiên, có một thách thức với điều này là để nhóm L2 sẵn sàng nỗ lực áp dụng một đề xuất, họ cần phải tin tưởng rằng L1 và/hoặc các L2 khác sau này sẽ áp dụng điều gì đó tương thích.

Một ứng dụng khác mà chúng ta cần xem xét rõ ràng là tài khoản kho khóa, lưu trữ trạng thái liên quan đến tài khoản trên L1 hoặc L2 chuyên dụng, nhưng có thể được sử dụng trên L1 và bất kỳ L2 tương thích nào. Để thực hiện việc này một cách hiệu quả có thể yêu cầu L2 hỗ trợ các mã hoạt động như L1SLOAD hoặc REMOTESTATICCALL, mặc dù nó cũng sẽ yêu cầu triển khai tính năng trừu tượng hóa tài khoản trên L2 để hỗ trợ.

Nó tương tác với các phần khác của lộ trình như thế nào?

Danh sách kèm theo cần hỗ trợ các giao dịch tóm tắt tài khoản. Trên thực tế, nhu cầu về danh sách ngăn chặn và nhu cầu về nhóm bộ nhớ phi tập trung cuối cùng rất giống nhau, mặc dù danh sách ngăn chặn linh hoạt hơn một chút. Ngoài ra, lý tưởng nhất là việc triển khai trừu tượng hóa tài khoản nên được phối hợp trên L1 và L2 càng nhiều càng tốt. Nếu trong tương lai, chúng tôi kỳ vọng rằng hầu hết người dùng sẽ sử dụng tính năng tổng hợp kho khóa thì thiết kế trừu tượng hóa tài khoản sẽ tính đến điều này.

Cải tiến EIP-1559

Nó giải quyết được vấn đề gì?

EIP-1559 ra mắt trên Ethereum vào năm 2021 và cải thiện đáng kể thời gian đưa khối trung bình vào.

Tuy nhiên, EIP- Việc triển khai 1559 hiện tại không hoàn hảo ở một số khía cạnh:

• Công thức hơi sai sót : Thay vì nhắm mục tiêu 50% số khối, nó nhắm mục tiêu ~50-53% số khối hoàn chỉnh tùy thuộc vào phương sai (điều này liên quan đến cái mà các nhà toán học gọi là "bất đẳng thức AM-GM");

< li>

Nó không điều chỉnh đủ nhanh trong điều kiện khắc nghiệt.

Công thức sau này cho các đốm màu (EIP-4844) được thiết kế rõ ràng để giải quyết vấn đề đầu tiên và nói chung là ngắn gọn hơn. Cả EIP-1559 và EIP-4844 đều không cố gắng giải quyết vấn đề thứ hai. Vì vậy, hiện trạng là một trạng thái nửa vời khó hiểu liên quan đến hai cơ chế khác nhau và thậm chí có trường hợp cả hai đều cần được cải thiện theo thời gian.

Ngoài ra, còn có những điểm yếu khác trong việc định giá tài nguyên Ethereum không liên quan đến EIP-1559 nhưng có thể được giải quyết bằng cách điều chỉnh EIP-1559. Vấn đề chính là sự khác biệt giữa trường hợp trung bình và trường hợp xấu nhất: giá tài nguyên trong Ethereum phải được đặt để xử lý trường hợp xấu nhất, trong đó toàn bộ mức tiêu thụ gas của một khối chiếm một tài nguyên, nhưng mức sử dụng trong trường hợp trung bình thấp hơn nhiều. dẫn đến hiệu quả thấp.

Nó là gì? Nó hoạt động như thế nào?

Giải pháp cho những sự kém hiệu quả này là khí đốt đa chiều: đặt ra các mức giá và giới hạn khác nhau cho các nguồn tài nguyên khác nhau. Khái niệm này độc lập về mặt kỹ thuật với EIP-1559, nhưng EIP-1559 làm cho nó dễ dàng hơn: không có EIP-1559, việc đóng gói các khối một cách tối ưu với nhiều hạn chế về tài nguyên là một vấn đề phức tạp về chiếc ba lô đa chiều. Với EIP-1559, hầu hết các khối không được tải đầy đủ trên bất kỳ tài nguyên nào, vì vậy thuật toán đơn giản "chấp nhận bất kỳ thứ gì trả đủ phí" sẽ đủ.

Ngày nay, chúng ta có khí đa chiều để thực thi và các đốm màu; về nguyên tắc, chúng ta có thể tăng điều này lên nhiều chiều hơn: dữ liệu cuộc gọi, đọc/ghi trạng thái và mở rộng kích thước trạng thái.

EIP-7706 giới thiệu một phương diện gas mới cho dữ liệu cuộc gọi. Đồng thời, nó đơn giản hóa cơ chế khí đa chiều bằng cách làm cho cả ba loại khí thuộc về một khung (kiểu EIP-4844), từ đó cũng giải quyết được những thiếu sót về mặt toán học của EIP-1559.

EIP-7623 là một giải pháp chính xác hơn cho vấn đề tài nguyên trong trường hợp trung bình và trong trường hợp xấu nhất, giúp hạn chế chặt chẽ hơn dữ liệu cuộc gọi tối đa mà không đưa ra một chiều hướng hoàn toàn mới.

Một hướng đi xa hơn là giải quyết vấn đề tốc độ cập nhật và tìm ra thuật toán tính phí cơ sở nhanh hơn trong khi vẫn giữ lại các bất biến chính được đưa ra bởi cơ chế EIP-4844 (tức là: về lâu dài, mức sử dụng trung bình hoàn toàn gần mục tiêu).

Có những nghiên cứu nào hiện có?

Câu hỏi thường gặp về EIP-1559: https://notes.ethereum.org/@vbuterin/eip-1559-faq

Phân tích thực nghiệm EIP-1559: https://dl.acm.org/doi/10.1145/3548606.3559341

Các cải tiến được đề xuất để cho phép Tinh chỉnh nhanh chóng: https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/Transaction_Fees_on_a_Honeymoon_Ethereums_EIP_1559_One_Month_Later.pdf

EIP -4844 Câu hỏi thường gặp về cơ chế tính phí cơ bản: https://notes.ethereum .org/@vbuterin/proto_danksharding_faq#How-does-the-exponential-EIP-1559-blob-fee- adjustment-mechanism-work

EIP-7706: https://eips .ethereum.org/EIPS/eip-7706

EIP-7623:https://eips.ethereum.org/EIPS/eip-7623

Những gì còn lại để làm và sự đánh đổi là gì?

Khí đa chiều có hai sự đánh đổi chính:

• Nó làm tăng độ phức tạp của giao thức

• Nó làm tăng độ phức tạp của thuật toán tối ưu cần thiết để lấp đầy các khối theo dung lượng

Độ phức tạp của giao thức là một vấn đề tương đối nhỏ đối với calldata, nhưng lại là vấn đề lớn hơn nhiều đối với các kích thước khí "bên trong EVM" (ví dụ: đọc và ghi bộ lưu trữ). Vấn đề là không chỉ người dùng đặt giới hạn gas: các hợp đồng cũng đặt giới hạn khi họ gọi các hợp đồng khác. Và ngày nay, cách duy nhất họ có thể đặt ra giới hạn là một chiều.

Một cách đơn giản để loại bỏ vấn đề này là chỉ cung cấp gas đa chiều bên trong EOF, vì EOF không cho phép các hợp đồng đặt giới hạn gas khi gọi các hợp đồng khác. Các hợp đồng không phải EOF phải thanh toán tất cả các loại phí gas khi thực hiện các hoạt động lưu trữ (ví dụ: nếu SLOAD tốn 0,03% giới hạn gas truy cập lưu trữ khối thì người dùng không phải EOF cũng sẽ bị tính phí 0,03% giới hạn gas thực thi)

Nghiên cứu thêm về khí đa chiều sẽ giúp hiểu được sự đánh đổi và tìm ra sự cân bằng lý tưởng.

Nó tương tác với các phần khác của lộ trình như thế nào?

Việc triển khai thành công Gas đa chiều có thể giảm đáng kể việc sử dụng tài nguyên trong "trường hợp xấu nhất" nhất định, từ đó giảm áp lực tối ưu hóa hiệu suất để hỗ trợ, chẳng hạn như cây nhị phân dựa trên hàm băm STARKed. Đặt mục tiêu cứng rắn cho tăng trưởng quy mô tiểu bang sẽ giúp các nhà phát triển khách hàng lập kế hoạch và ước tính nhu cầu trong tương lai của họ dễ dàng hơn.

Như đã đề cập ở trên, vì EOF có khả năng không thể quan sát được Gas nên phiên bản Gas đa chiều cực đoan hơn sẽ dễ thực hiện hơn.

Hàm độ trễ có thể xác minh (VDF)

Nó giải quyết được vấn đề gì?

Ngày nay, Ethereum sử dụng tính ngẫu nhiên dựa trên RANDAO để chọn ra những người đề xuất. Tính ngẫu nhiên dựa trên RANDAO hoạt động bằng cách yêu cầu mỗi người đề xuất tiết lộ một bí mật mà họ đã cam kết trước và trộn từng bí mật được tiết lộ vào tính ngẫu nhiên. Vì vậy, mỗi người đề xuất có “1 sức mạnh thao túng”: họ có thể thay đổi tính ngẫu nhiên bằng cách không xuất hiện (với một cái giá phải trả). Điều này có ý nghĩa đối với những người đề xuất, vì ít người có thể tạo cho mình hai cơ hội đề xuất mới bằng cách từ bỏ một cơ hội đề xuất. Nhưng đối với các ứng dụng on-chain yêu cầu tính ngẫu nhiên thì điều này là không thể. Lý tưởng nhất là chúng ta sẽ tìm thấy những nguồn ngẫu nhiên mạnh mẽ hơn.

Nó là gì vậy? Nó hoạt động như thế nào?

Hàm độ trễ có thể kiểm chứng là một hàm chỉ có thể được đánh giá một cách tuần tự và không thể được tăng tốc bằng cách song song hóa. Một ví dụ đơn giản là phép băm lặp lại: tính i trong phạm vi (10**9): x = hash(x). Đầu ra đã được kiểm chứng SNARK về tính chính xác và có thể được sử dụng làm giá trị ngẫu nhiên. Ý tưởng là đầu vào được chọn dựa trên thông tin có sẵn tại thời điểm T, trong khi đầu ra không được xác định tại thời điểm T: nó sẽ chỉ khả dụng vào một thời điểm nào đó sau T nếu ai đó thực hiện tính toán đầy đủ. Bởi vì bất kỳ ai cũng có thể thực hiện các phép tính nên không có khả năng che giấu kết quả và do đó không có khả năng thao túng kết quả.

Rủi ro chính với các chức năng bị trì hoãn có thể kiểm chứng là sự tối ưu hóa ngẫu nhiên: ai đó tìm ra cách chạy chức năng nhanh hơn nhiều so với dự kiến, cho phép họ thao túng thông tin họ tiết lộ tại thời điểm T dựa trên kết quả đầu ra trong tương lai. Việc tối ưu hóa ngoài dự kiến ​​có thể xảy ra theo hai cách:

• Tăng tốc phần cứng: Ai đó đã tạo một ASIC vòng lặp tính toán của nó chạy nhanh hơn nhiều so với phần cứng hiện có.

• Song song hóa ngẫu nhiên: Ai đó đã tìm ra cách để chạy hàm nhanh hơn thông qua song song hóa, mặc dù làm như vậy đòi hỏi nhiều tài nguyên hơn gấp 100 lần.

Nhiệm vụ tạo ra một VDF thành công là tránh cả hai vấn đề trong khi vẫn hiệu quả và thiết thực (ví dụ: một vấn đề với các phương pháp dựa trên hàm băm là việc chứng minh SNARK theo thời gian thực rất khó để thực hiện trên các yêu cầu phần cứng là rất cao). Việc tăng tốc phần cứng thường được giải quyết bằng cách cho phép các tác nhân vì lợi ích công cộng tự tạo và phân phối một cách hợp lý gần với ASIC tối ưu cho VDF.

Có những nghiên cứu nào hiện có?

vdfresearch.org: https: //vdfresearch.org/

Suy nghĩ về các cuộc tấn công vào VDF được sử dụng trong Ethereum năm 2018: https://ethresear.ch /t /ver thể-delay-functions-and-Attack/2365

Một cuộc tấn công vào MinRoot, một VDF được đề xuất: https:// inria.hal.science /hal-04320126/file/minrootanalysis2023.pdf

Những gì còn lại phải làm và sự đánh đổi là gì?

Hiện tại chưa có cấu trúc VDF nào có thể đáp ứng đầy đủ mọi nhu cầu của các nhà nghiên cứu Ethereum. Cần phải làm nhiều việc hơn để tìm ra chức năng như vậy. Nếu chúng tôi có nó, sự đánh đổi chính sẽ chỉ là liệu có đưa nó vào hay không: một sự đánh đổi đơn giản giữa chức năng so với độ phức tạp của giao thức và rủi ro bảo mật. Nếu chúng tôi coi VDF là an toàn nhưng hóa ra lại không an toàn thì tùy thuộc vào cách nó được triển khai, mức độ bảo mật sẽ giảm xuống theo giả định RANDAO (thao tác 1 bit cho mỗi kẻ tấn công) hoặc tệ hơn. Vì vậy, ngay cả khi VDF bị hỏng, nó sẽ không phá vỡ giao thức nhưng sẽ phá vỡ ứng dụng hoặc bất kỳ chức năng giao thức mới nào phụ thuộc nhiều vào nó.

Nó tương tác với các phần khác của lộ trình như thế nào?

VDF là một thành phần tương đối độc lập của giao thức Ethereum, nhưng ngoài việc cải thiện tính bảo mật của việc lựa chọn người đề xuất, nó có thể được sử dụng cho (i) các ứng dụng trên chuỗi dựa vào tính ngẫu nhiên và có khả năng (ii ) Nhóm bộ nhớ được mã hóa, mặc dù việc tạo nhóm bộ nhớ được mã hóa dựa trên VDF vẫn dựa vào các khám phá mã hóa khác chưa xảy ra.

Một điều cần nhớ là do tính không chắc chắn của phần cứng nên sẽ có một số "khoảng cách" giữa thời điểm đầu ra VDF được tạo ra và thời điểm đầu ra được yêu cầu. Điều này có nghĩa là thông tin sẽ có sẵn cách đây vài khối. Đây có thể là một chi phí có thể chấp nhận được nhưng cần được xem xét khi quyết định một bể chứa duy nhất hoặc các thiết kế lựa chọn của ủy ban, v.v.

Sự rối mã và chữ ký một lần: tương lai của mật mã

Nó giải quyết được vấn đề gì?

Một trong những bài viết nổi tiếng nhất của Nick Szabo là bài viết năm 1997 về “Thỏa thuận của Chúa”. Trong bài viết, ông lưu ý rằng các ứng dụng đa bên thường dựa vào “các bên thứ ba đáng tin cậy” để quản lý các tương tác. Theo quan điểm của ông, vai trò của mật mã là tạo ra một bên thứ ba đáng tin cậy được mô phỏng để thực hiện cùng một công việc mà không thực sự yêu cầu sự tin tưởng vào bất kỳ người tham gia cụ thể nào.

"Giao thức đáng tin cậy về mặt toán học", sơ đồ của Nick Szabo

Cho đến nay chúng ta chỉ có thể tiến gần đến điều này lý tưởng. Nếu tất cả những gì chúng ta cần là một máy tính ảo minh bạch, nơi dữ liệu và tính toán không thể bị tắt, kiểm duyệt hoặc giả mạo, nhưng quyền riêng tư không phải là mục tiêu, thì blockchain có thể làm được điều đó, mặc dù khả năng mở rộng hạn chế. Nếu quyền riêng tư là mục tiêu thì cho đến gần đây chúng ta chỉ có thể có một vài giao thức cụ thể cho các ứng dụng cụ thể: chữ ký số để xác thực cơ bản, chữ ký vòng và chữ ký vòng có thể liên kết để ẩn danh thô, mã hóa dựa trên nhận dạng (cho phép mã hóa thuận tiện hơn theo các giả định cụ thể về nhà phát hành đáng tin cậy), chữ ký mù cho tiền điện tử Chaumian, v.v. Cách tiếp cận này đòi hỏi rất nhiều công việc cho mỗi ứng dụng mới.

Vào những năm 2010, lần đầu tiên chúng tôi thấy một cách tiếp cận khác và mạnh mẽ hơn dựa trên mã hóa có thể lập trình. Thay vì tạo các giao thức mới cho mọi ứng dụng mới, chúng ta có thể sử dụng các giao thức mới mạnh mẽ (đặc biệt là ZK-SNARK) để thêm các đảm bảo về mật mã cho các chương trình tùy ý. ZK-SNARK cho phép người dùng chứng minh các tuyên bố tùy ý về dữ liệu họ nắm giữ theo cách (i) có thể dễ dàng xác minh và (ii) không tiết lộ bất kỳ dữ liệu nào ngoài chính tuyên bố đó. Đây là một bước tiến lớn về quyền riêng tư và khả năng mở rộng và tôi ví nó giống như hiệu ứng biến áp trong trí tuệ nhân tạo. Hàng nghìn người làm việc trên một ứng dụng cụ thể trong một năm đột nhiên được thay thế bằng một giải pháp chung chung mà bạn có thể áp dụng để giải quyết một loạt vấn đề đáng ngạc nhiên.

Nhưng ZK-SNARK chỉ là sản phẩm đầu tiên trong số ba sản phẩm nguyên thủy có mục đích chung cực kỳ mạnh mẽ tương tự. Những giao thức này mạnh mẽ đến mức khi tôi nghĩ đến chúng, chúng khiến tôi nhớ đến một bộ bài cực kỳ mạnh mẽ từ Yu-Gi-Oh, một trò chơi bài và chương trình truyền hình mà tôi đã chơi rất nhiều khi còn nhỏ. Và kìa: Lá bài của các vị thần Ai Cập. Các lá bài Thần Ai Cập là ba lá bài cực kỳ mạnh mẽ mà theo truyền thuyết, có thể gây chết người khi tạo ra và mạnh đến mức chúng không được phép sử dụng trong các trận đấu tay đôi. Tương tự, trong mật mã, chúng ta có ba giao thức thần Ai Cập:

Nó là gì vậy? Nó hoạt động như thế nào?

ZK-SNARK là một trong ba giao thức mà chúng tôi đã có và đã đạt đến mức độ hoàn thiện cao. Trong 5 năm qua, ZK-SNARK đã có những bước tiến lớn trong việc chứng minh tốc độ và sự thân thiện với nhà phát triển, trở thành nền tảng cho chiến lược bảo mật và khả năng mở rộng của Ethereum. Nhưng ZK-SNARK có một hạn chế quan trọng: bạn cần biết dữ liệu để chứng minh điều đó. Mọi trạng thái trong ứng dụng ZK-SNARK đều phải có "chủ sở hữu" phải có mặt để phê duyệt mọi hoạt động đọc hoặc ghi vào ứng dụng đó.

Giao thức thứ hai không có hạn chế này, mã hóa đồng hình hoàn toàn (FHE). FHE cho phép bạn thực hiện bất kỳ phép tính nào trên dữ liệu được mã hóa mà không cần xem dữ liệu. Điều này cho phép bạn thực hiện tính toán trên dữ liệu người dùng vì lợi ích của người dùng, đồng thời giữ kín dữ liệu và thuật toán. Nó cũng cho phép bạn mở rộng các hệ thống bỏ phiếu như MACI để có được sự riêng tư và bảo mật gần như hoàn hảo. Trong một thời gian dài, FHE được coi là quá kém hiệu quả để sử dụng thực tế, nhưng giờ đây nó cuối cùng đã trở nên đủ hiệu quả để chúng ta bắt đầu thấy các ứng dụng.

Cursive là một ứng dụng sử dụng điện toán chung và FHE để tiến hành khám phá các lợi ích chung mà vẫn đảm bảo quyền riêng tư.

Nhưng FHE có những hạn chế: mọi công nghệ dựa trên FHE vẫn cần có người giữ khóa giải mã. Đây có thể là thiết lập phân tán M-of-N và thậm chí bạn có thể thêm lớp phòng thủ thứ hai bằng TEE, nhưng đó vẫn là một hạn chế.

Điều này đưa chúng ta đến giao thức thứ ba, mạnh hơn hai giao thức còn lại cộng lại: che giấu không thể phân biệt được. Mặc dù còn lâu mới hoàn thiện nhưng tính đến năm 2020, chúng tôi đã có một giao thức hợp lệ về mặt lý thuyết dựa trên các giả định bảo mật tiêu chuẩn và gần đây đã bắt đầu công việc triển khai. Tính năng che giấu không thể phân biệt được cho phép bạn tạo một "chương trình được mã hóa" thực hiện các phép tính tùy ý để ẩn tất cả các chi tiết bên trong của chương trình. Một ví dụ đơn giản, bạn có thể đặt khóa riêng của mình vào một chương trình bị xáo trộn, chương trình này chỉ cho phép bạn sử dụng nó để ký các số nguyên tố và phân phối chương trình này cho người khác. Họ có thể sử dụng chương trình để ký bất kỳ số nguyên tố nào, nhưng họ không thể trích xuất khóa. Nhưng nó còn làm được nhiều hơn thế: được sử dụng với hàm băm, nó có thể được sử dụng để triển khai bất kỳ mật mã nguyên thủy nào khác và thậm chí còn hơn thế nữa.

Điều duy nhất mà một chương trình che giấu mã nguồn không thể làm là ngăn chặn việc sao chép chính nó. Nhưng để làm được điều đó, một thứ thậm chí còn mạnh mẽ hơn sắp xuất hiện, mặc dù điều đó phụ thuộc vào việc mọi người đều có máy tính lượng tử: chữ ký lượng tử một lần.

Sử dụng tính năng che giấu mã nguồn và With chữ ký một lần, chúng ta có thể xây dựng một bên thứ ba không cần sự tin cậy gần như hoàn hảo. Điều duy nhất chúng ta không thể làm chỉ bằng cách sử dụng mật mã và điều chúng ta vẫn cần blockchain làm là đảm bảo khả năng chống kiểm duyệt. Những công nghệ này sẽ cho phép chúng tôi không chỉ làm cho Ethereum an toàn hơn mà còn xây dựng các ứng dụng mạnh mẽ hơn trên Ethereum.

Để hiểu cách mỗi nguyên hàm này bổ sung thêm chức năng bổ sung, hãy xem một ví dụ chính: biểu quyết. Bỏ phiếu là một vấn đề hấp dẫn vì nó có nhiều đặc tính bảo mật phức tạp cần được đáp ứng, bao gồm khả năng xác minh và quyền riêng tư rất mạnh mẽ. Mặc dù các giao thức bỏ phiếu có tính bảo mật mạnh mẽ đã tồn tại trong nhiều thập kỷ, nhưng hãy làm cho vấn đề trở nên khó khăn hơn bằng cách nói rằng chúng tôi muốn một thiết kế có thể xử lý các giao thức bỏ phiếu tùy ý: bỏ phiếu bậc hai, tài trợ bậc hai giới hạn theo cặp, tài trợ thứ cấp khớp với cụm, v.v. Tức là chúng ta muốn bước "đếm" là một thủ tục tùy ý.

• Đầu tiên, giả sử chúng ta công khai cuộc bỏ phiếu trên blockchain. Điều này mang lại cho chúng tôi khả năng xác minh công khai (bất kỳ ai cũng có thể xác minh rằng kết quả cuối cùng là chính xác, bao gồm các quy tắc kiểm phiếu và tiêu chuẩn) và khả năng chống kiểm duyệt (không thể ngăn cản mọi người bỏ phiếu). Nhưng chúng tôi không có sự riêng tư.

• Sau đó, chúng tôi thêm ZK-SNARK. Giờ đây, chúng tôi có quyền riêng tư: mọi cuộc bỏ phiếu đều ẩn danh đồng thời đảm bảo rằng chỉ những cử tri được ủy quyền mới có thể bỏ phiếu và mỗi cử tri chỉ có thể bỏ phiếu một lần.

• Bây giờ, chúng ta thêm cơ chế MACI. Phiếu bầu được mã hóa đến máy chủ trung tâm bằng khóa giải mã. Máy chủ trung tâm cần chạy quy trình kiểm phiếu, bao gồm loại bỏ các phiếu bầu trùng lặp và đưa ra ZK-SNARK chứng minh câu trả lời. Điều này duy trì sự đảm bảo trước đó (ngay cả khi máy chủ gian lận!), nhưng nó bổ sung thêm một sự đảm bảo chống cưỡng bức nếu máy chủ trung thực: người dùng không thể chứng minh cách họ bỏ phiếu, ngay cả khi họ muốn. Điều này là do, mặc dù người dùng có thể chứng minh rằng họ đã bỏ phiếu nhưng họ không thể chứng minh rằng họ đã không bỏ phiếu khác khiến phiếu bầu đó bị hủy. Điều này ngăn chặn hối lộ và các cuộc tấn công khác.

• Chúng tôi thực hiện kiểm phiếu trong FHE và sau đó thực hiện phép tính giải mã ngưỡng N/2-of-N để giải mã nó. Điều này làm cho khả năng chống cưỡng bức được đảm bảo là N/2-of-N, thay vì 1-of-1.

• Chúng tôi đã làm xáo trộn quy trình kiểm phiếu và thiết kế quy trình che giấu để nó chỉ có thể đưa ra kết quả đầu ra khi được phép, thông qua Bằng chứng đồng thuận blockchain hoặc thông qua một lượng bằng chứng công việc nhất định , hoặc cả hai. Điều này làm cho bảo đảm chống thực thi gần như hoàn hảo: trong trường hợp đồng thuận blockchain, bạn cần 51% người xác thực thông đồng để phá vỡ nó, trong khi trong trường hợp bằng chứng công việc, ngay cả khi mọi người thông đồng, hãy chạy lại với một tập hợp con khác nhau Việc kiểm phiếu của cử tri nhằm cố gắng trích xuất từng cử tri cũng sẽ rất tốn kém. Chúng tôi thậm chí có thể yêu cầu chương trình thực hiện những điều chỉnh ngẫu nhiên nhỏ đối với kết quả cuối cùng, khiến việc trích xuất hành vi của từng cử tri trở nên khó khăn hơn.

• Chúng tôi đã thêm chữ ký một lần, một phương pháp cơ bản dựa trên điện toán lượng tử để cho phép chữ ký chỉ được sử dụng một lần để ký một loại tin nhắn nhất định. Điều này làm cho việc đảm bảo chống cưỡng bức thực sự hoàn hảo.

Sự nhầm lẫn về khả năng phân biệt cũng có thể tạo điều kiện cho các ứng dụng mạnh mẽ khác. Ví dụ:

• DAO, đấu giá trực tuyến và các ứng dụng khác có nội bộ tùy ý chương trình các quốc gia bí mật

• Một thiết lập đáng tin cậy thực sự phổ quát: ai đó có thể tạo một chương trình bị xáo trộn có chứa khóa và chạy bất kỳ chương trình nào và cung cấp đầu ra, lấy hàm băm (khóa, chương trình) làm đầu vào. Đưa nó vào chương trình. Với một chương trình như vậy, bất kỳ ai cũng có thể thả chương trình đó vào chính nó, kết hợp các khóa hiện có của chương trình với khóa riêng của họ và mở rộng quá trình thiết lập trong quy trình. Điều này có thể được sử dụng để tạo cài đặt đáng tin cậy 1/N cho bất kỳ giao thức nào.

• ZK-SNARKs, việc xác minh chỉ là chữ ký. Để đạt được điều này thật đơn giản: có một thiết lập đáng tin cậy và ai đó tạo một chương trình bị xáo trộn sẽ chỉ ký các tin nhắn bằng một khóa nếu đó là ZK-SNARK hợp lệ.

• Nhóm bộ nhớ được mã hóa. Việc giao dịch tiền điện tử trở nên dễ dàng đến mức nó chỉ có thể được giải mã khi một số sự kiện trên chuỗi xảy ra trong tương lai. Điều này thậm chí có thể bao gồm việc thực hiện VDF thành công.

Với chữ ký một lần, chúng tôi có thể làm cho chuỗi khối miễn nhiễm với các cuộc tấn công đảo ngược cuối cùng 51%, mặc dù các cuộc tấn công kiểm duyệt vẫn có thể xảy ra. Những tính năng cơ bản như chữ ký một lần có thể cho phép các loại tiền lượng tử giải quyết vấn đề chi tiêu gấp đôi mà không cần đến blockchain, mặc dù nhiều ứng dụng phức tạp hơn vẫn sẽ yêu cầu blockchain.

Nếu những nguyên tắc cơ bản này đủ hiệu quả thì hầu hết các ứng dụng trên thế giới đều có thể được phân cấp. Nút thắt chính nằm ở việc xác minh tính đúng đắn của việc thực hiện.

Có những nghiên cứu nào hiện có?

Giao thức che giấu khả năng phân biệt năm 2021: https://eprint.iacr.org/2021/1334.pdf

Làm thế nào che giấu có thể giúp ích cho Ethereum: https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380

Cấu trúc chữ ký một lần được biết đến lần đầu tiên: https ://eprint.iacr.org/2020/107.pdf

Cố gắng triển khai khó hiểu (1):https:/// /mediatum.ub .tum.de/doc/1246288/1246288.pdf

Đã cố gắng triển khai một cách khó hiểu (2): https://github.com/SoraSuegami/iOMaker/tree/ main

Còn lại những gì phải làm và những đánh đổi là gì?

Vẫn còn nhiều việc phải làm. Việc che giấu tính không thể phân biệt vẫn còn rất non nớt và các cấu trúc ứng cử viên chậm hơn hàng triệu lần (hoặc hơn) so với ứng dụng. Sự xáo trộn không thể phân biệt nổi tiếng vì chạy trong thời gian đa thức "lý thuyết", nhưng trên thực tế mất nhiều thời gian hơn thời gian tồn tại của vũ trụ. Các giao thức mới hơn giúp thời gian chạy ít khắc nghiệt hơn nhưng chi phí chung vẫn quá cao để sử dụng thường xuyên: một người triển khai ước tính thời gian chạy là một năm.

Máy tính lượng tử thậm chí không tồn tại: tất cả cấu trúc bạn có thể đọc trên internet ngày nay đều là nguyên mẫu không thể thực hiện bất kỳ phép tính nào lớn hơn 4 bit hoặc không phải là máy tính lượng tử thực sự, mặc dù chúng có thể chứa các phần lượng tử, nhưng chúng không thể chạy các phép tính thực sự có ý nghĩa, chẳng hạn như thuật toán của Shor hoặc thuật toán của Grover. Gần đây, đã có những dấu hiệu cho thấy máy tính lượng tử “thực sự” không còn quá xa vời nữa. Tuy nhiên, ngay cả khi máy tính lượng tử "thực sự" sớm xuất hiện, ngày mà người bình thường có máy tính lượng tử trên máy tính xách tay hoặc điện thoại di động của họ có thể phải mất hàng thập kỷ trước khi các tổ chức hùng mạnh có quyền truy cập vào máy tính lượng tử có khả năng phá vỡ mật mã đường cong elip.

Đối với việc che giấu tính không thể phân biệt được, sự cân bằng quan trọng là giả định về bảo mật. Có nhiều thiết kế cấp tiến hơn sử dụng các giả định kỳ lạ. Chúng thường có thời gian chạy thực tế hơn, nhưng các giả định tưởng tượng đôi khi bị phá vỡ. Theo thời gian, cuối cùng chúng ta có thể tìm hiểu đủ về mạng để đưa ra những giả định không thể bị phá vỡ. Tuy nhiên, con đường này nguy hiểm hơn. Một cách tiếp cận thận trọng hơn sẽ là sử dụng các giao thức có độ bảo mật được coi là "tiêu chuẩn", nhưng điều này có thể có nghĩa là phải mất nhiều thời gian hơn trước khi chúng ta có được một giao thức chạy đủ nhanh.

Nó tương tác với các phần khác của lộ trình như thế nào?

Mã hóa cực kỳ mạnh có thể thay đổi cuộc chơi. Ví dụ:

• Nếu chúng tôi có được ZK-SNARK dễ xác minh với tư cách là chữ ký, chúng tôi có thể không cần bất kỳ giao thức tổng hợp nào; chúng tôi có thể xác minh trực tiếp trên chuỗi.

• Chữ ký một lần có thể mang lại giao thức bằng chứng cổ phần an toàn hơn.

• Nhiều giao thức bảo mật phức tạp có thể được thay thế bằng cách "chỉ" có EVM bảo vệ quyền riêng tư.

• Nhóm bộ nhớ được mã hóa trở nên dễ triển khai hơn.

Đầu tiên, lợi ích sẽ xảy ra ở lớp ứng dụng, vì Ethereum L1 vốn yêu cầu các giả định bảo mật thận trọng. Tuy nhiên, ngay cả việc chỉ sử dụng lớp ứng dụng cũng có thể thay đổi cuộc chơi, như trường hợp xuất hiện của ZK-SNARK.