Tiêu đề gốc: Tương lai có thể có của giao thức Ethereum, phần 6: The Splurge
Tác giả gốc: @VitalikButerin
Bản tổng hợp gốc: zhouzhou, BlockBeats
Sau đây là nội dung gốc (nội dung gốc đã được chỉnh sửa cho dễ đọc và dễ hiểu):
Một số thứ khó có thể xếp vào một danh mục duy nhất và có nhiều “chi tiết nhỏ” trong thiết kế giao thức Ethereum rất quan trọng đối với sự thành công của Ethereum. Trên thực tế, khoảng một nửa nội dung đề cập đến các loại cải tiến EVM khác nhau và phần còn lại bao gồm các chủ đề thích hợp khác nhau, đó chính là nội dung của phát triển mạnh.
Lộ trình 2023: Thịnh vượng
Thịnh vượng: mục tiêu quan trọng
Biến EVM thành trạng thái cuối 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, cho phép tất cả người dùng tận hưởng 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, tăng khả năng mở rộng đồng thời giảm thiểu rủi ro
Khám phá mật mã nâng cao để cải thiện đáng kể Ethereum về lâu dài
Nội dung của chương này
VDF (Chức năng trễ có thể xác minh)
Làm xáo trộn và chữ ký một lần: tương lai lâu dài của mật mã
Cải tiến EVM
Vấn đề gì đã được giải quyết?
EVM hiện tại khó phân tích tĩnh, điều này gây khó khăn cho việc triển khai hiệu quả, xác minh chính thức mã và thực hiện các phần mở rộng tiếp theo. Ngoài ra, EVM không hiệu quả và khó triển khai nhiều dạng mật mã nâng cao trừ khi được hỗ trợ rõ ràng thông qua quá trình biên dịch trước.
Nó là gì và nó 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ã EVM mới với một số đặc điểm độc đáo, đáng chú ý nhất là:
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)
Nhảy động bị cấm và chỉ cho phép nhảy tĩnh
Mã EVM không còn có thể quan sát thông tin liên quan đến nhiên liệu
Đã thêm cơ chế chương trình con rõ ràng mới
Cấu trúc mã EOF
Boom: Cải tiến EVM (tiếp theo)
Các hợp đồng kế thừa sẽ tiếp tục tồn tại và có thể được tạo, mặc dù cuối cùng chúng có thể bị loại bỏ dần (và thậm chí có thể bị buộc phải sử dụng 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 là từ mã byte nhỏ hơn một chút thông qua các tính năng chương trình con và sau đó là từ chức năng mới dành riêng cho EOF hoặc giảm chi phí gas.
Sau khi giới thiệu EOF, việc nâng cấp thêm đã trở nên dễ dàng hơn. Phát triể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 dành riêng cho số học mô-đun và đặt chúng vào một không gian bộ nhớ mới không thể truy cập được bằng các opcode khác, giúp có thể sử dụng các tính năng 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 các tính năng Nhiều dữ liệu hướng dẫn đơn (SIMD) đã là một ý tưởng trong Ethereum trong một thời gian dài và lần đầu tiên được đề xuất bởi EIP-616 của Greg Colvin . SIMD có thể được sử dụng để tăng tốc nhiều dạng mật mã, bao gồm hàm băm, STARK 32 bit và mật mã dựa trên mạng. Sự kết hợp giữa EVM-MAX và SIMD làm cho hai tiện ích mở rộng hướng đến hiệu suất này trở thành một cặp đôi tự nhiên.
Thiết kế sơ bộ của EIP kết hợp sẽ bắt đầu với EIP-6690 và sau đó:
Cho phép (i) bất kỳ số lẻ nào hoặc (ii) bất kỳ lũy thừa nào từ 2 đến 2768 dưới dạng mô đun
Đối với mỗi mã opcode EVM-MAX (cộng, trừ, nhân), hãy thêm một phiên bản thay vì sử dụng 3 tức thời x, y, z, sử dụng 7 tức thời: x_start, x_skip, y_start, y_skip , z_start, z_skip, count. Trong mã Python, các opcode này hoạt động như sau:
cho tôi trong phạm vi (đếm):
mem[z_start + z_skip * count] = op(
mem[x_start + x_skip * count],
mem[y_start + y_skip * count]
)
Trong quá trình triển khai thực tế, điều này sẽ được xử lý song song.
Có thể thêm XOR, AND, OR, NOT và SHIFT (cả tuần hoàn và không tuần hoàn), ít nhất là đối với lũy thừa 2 modulo. Đồng thời thêm ISZERO (đẩy đầu ra vào ngăn xếp chính EVM), đủ mạnh để triển khai mật mã đường cong elip, mật mã miền nhỏ (như Poseidon, Circle STARK), hàm băm truyền thống (như SHA 256, 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 ít được chú ý hơn.
Liên kết đến nghiên cứu hiện có
EOF: https://evmobjectformat.org/
EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
SIMD: https://eips.ethereum.org/EIPS/eip-616
Công việc còn lại và sự đánh đổi
Hiện tại, EOF dự kiến sẽ được đưa vào đợt hard fork tiếp theo. Mặc dù bạn luôn có thể xóa nó vào phút cuối - các tính năng đã tạm thời bị xóa trong các đợt hard fork trước đó, nhưng làm như vậy sẽ khá khó khăn. Loại bỏ EOF có nghĩa là mọi nâng cấp trong tương lai đối với EVM sẽ cần được thực hiện mà không cần EOF, việc này có thể thực hiện được nhưng có thể khó khăn hơn.
Sự đánh đổi chính của EVM là độ phức tạp L1 và độ phức tạp của cơ sở hạ tầng EOF là một lượng lớn mã cần được thêm vào quá trình triển khai EVM và việc kiểm tra mã tĩnh cũng tương đối phức tạp. Tuy nhiên, đổi lại, chúng tôi nhận được các ngôn ngữ cấp cao được đơn giản hóa, việc triển khai EVM được đơn giản hóa và các lợi ích khác. Có thể nói, lộ trình ưu tiên cải tiến liên tục của Ethereum L1 nên bao gồm và xây dựng trên EOF.
Một công việc quan trọng cần được thực hiện là triển khai các chức năng tương tự EVM-MAX cộng với SIMD và đánh giá mức tiêu thụ gas của các hoạt động mã hóa khác nhau.
Làm cách nào để tương tác với các phần khác của lộ trình?
L1 điều chỉnh EVM của nó để L2 có thể dễ dàng điều chỉnh cho phù hợp hơn. Nếu cả hai không điều chỉnh đồng thời, nó có thể gây ra sự không tương thích và gây ra những ảnh hưởng bất lợi. Ngoài ra, EVM-MAX và SIMD có thể giảm chi phí gas của nhiều hệ thống thử nghiệm, giúp L2 hoạt động hiệu quả hơn. Nó cũng giúp dễ dàng thay thế việc biên dịch trước bằng mã EVM có thể thực hiện cùng một tác vụ mà không ảnh hưởng nhiều đến hiệu quả.
Trừu tượng hóa tài khoản
Vấn đề gì đã được giải quyết?
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, cho phép logic xác minh của tài khoản trở thành mã EVM tùy ý. Điều này cho phép một loạt các ứng dụng:
Chuyển sang mật mã kháng lượng tử
Xoay các 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
Sử dụng một khóa cho các hoạt động có giá trị thấp và một khóa khác (hoặc bộ khóa) cho các hoạt động có giá trị cao
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ỏ điểm phụ thuộc trung tâm quan trọng
Kể từ khi việc trừu tượng hóa tài khoản được đề xuất vào năm 2015, các mục tiêu của nó cũng đã mở rộng để bao gồm một số lượng lớn mục tiêu tiện lợi. Ví dụ: một tài khoản không có ETH nhưng một số ERC 20 có thể thanh toán gas bằng ERC 20. Dưới đây là biểu đồ tóm tắt về các mục tiêu này:
MPC (Tính toán đa bên) là công nghệ 40 năm tuổi được sử dụng để chia khóa thành nhiều phần và lưu trữ chúng trên nhiều thiết bị, sử dụng kỹ thuật mã hóa để tạo chữ ký mà không cần kết hợp trực tiếp các phần khóa.
EIP-7702 là một đề xuất dự kiến được giới thiệu trong đợt hard fork tiếp theo, EIP-7702 là kết quả của nhận thức ngày càng tăng về việc cung cấp sự thuận tiện cho việc trừu tượng hóa tài khoản nhằm mang lại lợi ích cho tất cả người dùng, bao gồm cả người dùng EOA và nhằm mục đích cải thiện tất cả người dùng trong thời gian ngắn trải nghiệm và tránh chia thành hai hệ sinh thái.
Công việc bắt đầu với EIP-3074 và cuối cùng dẫn đến EIP-7702. EIP-7702 cung cấp chức 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 ngày nay (tài khoản thuộc sở hữu bên ngoài, nghĩa là các tài khoản được kiểm soát bởi chữ ký ECDSA).
Như bạn có thể thấy trên biểu đồ, 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 các công nghệ gia tăng như tính toán nhiều bên hoặc EIP-7702, mục tiêu bảo mật chính của đề xuất trừu tượng hóa tài khoản ban đầu chỉ có thể được giải quyết bằng cách quay lại và giải quyết vấn đề ban đầu. Để đạt được: cho phép mã hợp đồng thông minh kiểm soát việc xác minh giao dịch. Lý do cho đến nay điều này vẫn chưa thể thực hiện được 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à nó hoạt động như thế nào?
Cốt lõi của việc trừu tượng hóa tài khoản rất đơn giản: cho phép các hợp đồng thông minh bắt đầu giao dịch, không chỉ EOA. Toàn bộ sự phức tạp đến từ việc triển khai điều này theo cách thân thiện để duy trì mạng lưới phi tập trung và bảo vệ khỏi các cuộc tấn công từ chối dịch vụ.
Một thách thức quan trọng điển hình là vấn đề đa lỗi:
Nếu có 1.000 tài khoản có chức năng xác minh đều phụ thuộc vào một giá trị S và giá trị hiện tại S làm cho tất cả các giao dịch trong mempool hợp lệ thì một giao dịch lật giá trị của S có thể khiến tất cả các giao dịch khác trong mempool hợp lệ. . Điều này cho phép kẻ tấn công gửi thư rác các giao dịch vào mempool với chi phí rất thấp, do đó làm tắc nghẽn tài nguyên của các nút mạng.
Sau nhiều năm làm việc chăm chỉ nhằm mở rộng chức năng đồng thời hạn chế rủi ro Từ chối Dịch vụ (DoS), giải pháp đạt được “sự trừu tượng hóa tài khoản lý tưởng” cuối cùng đã xuất hiện: ERC-4337.
ERC-4337 hoạt động bằng cách chia quá trình xử lý thao tác của người dùng 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, tất cả các thực thi được xử lý sau. 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 chỉ liên quan đến 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 vô hiệu. Ngoài ra, các giới hạn gas nghiêm ngặt được thực thi ở bước xác minh.
ERC-4337 được thiết kế như một tiêu chuẩn giao thức bổ sung (ERC) vì vào 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ó thêm năng lượng để xử lý các chức năng khác. Đó là lý do tại sao ERC-4337 sử dụng một đối tượng có tên Hành động của người dùng thay vì giao dịch thông thường. Tuy nhiên, gần đây chúng tôi nhận ra rằng ít nhất một số điều này cần phải được ghi vào giao thức.
Hai lý do chính như sau:
1. Sự kém hiệu quả vốn có của EntryPoint dưới dạng hợp đồng: chi phí cố định khoảng 100.000 gas mỗi gói và hàng nghìn gas bổ sung cho mỗi hoạt động của người dùng.
2. Sự cần thiết phải đảm bảo các thuộc tính Ethereum: Đảm bảo bao gồm được tạo bởi danh sách bao gồm cần phải được chuyển đến người dùng trừu tượng của tài khoản.
Ngoài ra, ERC-4337 còn mở rộng thêm 2 chức năng:
Paymasters: Một tính năng cho phép một tài khoản thanh toán phí thay mặt cho một tài khoản khác. Điều này vi phạm quy tắc rằng chỉ có tài khoản người gửi mới có thể được truy cập trong giai đoạn xác minh, do đó, biện pháp xử lý đặc biệt được đưa ra để đảm bảo tính bảo mật của cơ chế thanh toán chính.
Bộ tổng hợp: Hỗ trợ các chức năng tổng hợp chữ ký, chẳng hạn như tổng hợp BLS hoặc tổng 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 trên Rollup.
Liên kết đến nghiên cứu hiện có
Bài giảng về lịch sử trừu tượng của 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 được ghi vào giao thức): https://eips.ethereum.org/EIPS/eip-7562
EIP-7701 (trừu tượng hóa tài khoản giao thức ghi dựa trên EOF): https://eips.ethereum.org/EIPS/eip-7701
Công việc còn lại và sự đánh đổi
Điều chính cần được giải quyết hiện nay là làm thế nào để đưa hoàn toàn 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 gần đây được viết vào giao thức là EIP-7701 . Đề xuất này triển khai tính năng trừu tượng hóa tài khoản trên EOF. Một tài khoản có thể có phần mã riêng để xác minh và nếu tài khoản đã thiết lập phần mã đó thì mã sẽ được thực thi trong bước xác minh các giao dịch từ tài khoản đó.
Điều thú vị về cách tiếp cận này là nó minh họa rõ ràng hai quan điểm tương đương về việc trừu tượng hóa tài khoản cục bộ:
1. Đặt EIP-4337 thành một phần của giao thức
2. Một loại EOA mới trong đó thuật toán chữ ký là thực thi mã EVM
Nếu chúng tôi bắt đầu bằng cách đặt các giới hạn nghiêm ngặt về độ phức tạp của mã thực thi trong quá trình xác minh - không được phép truy cập vào trạng thái bên ngoài và thậm chí các giới hạn gas được đặt ban đầu cũng quá thấp để có hiệu quả đối với các ứng dụng bảo vệ quyền riêng tư hoặc kháng lượng tử - thì phương pháp này Tính bảo mật rất rõ ràng: chỉ cần thay thế xác minh ECDSA bằng việc thực thi mã EVM với khoảng 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 các giới hạn 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 chuyển tiếp cũng như khả năng chống lượng tử đều quan trọng. Để làm được điều này, chúng ta cần tìm những cách linh hoạt hơn để giải quyết rủi ro Từ chối dịch vụ (DoS) mà không yêu cầu các bước xác minh tối giản.
Sự đánh đổi chính dường như là viết một giải pháp nhanh chóng để làm hài lòng ít người hơn so với chờ đợi lâu hơn và có khả năng nhận được một giải pháp lý tưởng hơn. Cách tiếp cận kết hợp là viết một số trường hợp sử dụng nhanh hơn và dành nhiều thời gian hơn để khám phá 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, thách thức với điều này là nhóm L2 cần phải tự tin trong công việc áp dụng đề xuất trước khi họ sẵn sàng thực hiện nó, đặc biệt là để đảm bảo rằng L1 và/hoặc các L2 khác có thể áp dụng cách tiếp cận tương thích trong tương lai.
Một ứng dụng khác mà chúng ta cần xem xét rõ ràng là các tài khoản lưu trữ 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. Việc thực hiện điều 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ư L1S LOAD hoặc REMOTESTATICCALL , nhưng điều này cũng yêu cầu việc triển khai tính năng trừu tượng hóa tài khoản trên L2 hỗ trợ các hoạt động này.
Nó tương tác với các phần khác của lộ trình như thế nào?
Các danh sách được bao gồm cần hỗ trợ các giao dịch trừu tượng của tài khoản và trên thực tế, nhu cầu của các danh sách được bao gồm thực sự rất giống với nhu cầu của một mempool phi tập trung, mặc dù có sự linh hoạt hơn một chút đối với các danh sách được bao gồm. Ngoài ra, việc triển khai trừu tượng hóa tài khoản phải được phối hợp giữa L1 và L2 bất cứ khi nào có thể. Nếu trong tương lai, chúng tôi mong đợi hầu hết người dùng sử dụng tổng hợp bộ nhớ khóa thì thiết kế trừu tượng hóa tài khoản sẽ dựa trên điều này.
Cải tiến EIP-1559
Nó giải quyết được vấn đề gì?
EIP-1559 đã được kích hoạt trên Ethereum vào năm 2021, cải thiện đáng kể thời gian đưa khối trung bình vào.
thời gian chờ đợi
Tuy nhiên, việc triển khai EIP-1559 hiện tại chưa hoàn hảo về nhiều mặt:
1. Công thức hơi thiếu sót: nó không nhắm mục tiêu 50% số khối mà nhắm tới khoảng 50-53% số khối đầy đủ, tùy thuộc vào phương sai (điều này không phù hợp với cái mà các nhà toán học gọi là bất đẳng thức trung bình số học-hình học có liên quan).
2. Không điều chỉnh đủ nhanh trong những tình huống khắc nghiệt.
Công thức sau cho các đốm màu (EIP-4844) được thiết kế đặc biệt để giải quyết vấn đề đầu tiên và nhìn chung đơn giản hơn. Tuy nhiên, cả EIP-1559 và EIP-4844 đều không cố gắng giải quyết vấn đề thứ hai. Do đó, hiện trạng là một trạng thái ở giữa lộn xộn bao gồm hai cơ chế khác nhau và có lập luận cho rằng cả hai cơ chế này sẽ 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 thông qua các điều chỉnh đối với EIP-1559. Một trong những vấn đề chính là sự khác biệt giữa các kịch bản 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 sẽ chiếm một tài nguyên, nhưng mức sử dụng trung bình thực tế là thấp hơn nhiều so với mức này, dẫn đến kém hiệu quả.
Khí đa chiều là gì và nó hoạt động như thế nào?
Giải pháp cho những sự thiếu hiệu quả này là Gas đ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 sự tồn tại của EIP-1559 giúp việc triển khai giải pháp này dễ dàng hơn. Nếu không có EIP-1559, việc đóng gói một cách tối ưu một khối chứa nhiều hạn chế về tài nguyên là một vấn đề về chiếc ba lô đa chiều phức tạp . Với EIP-1559, hầu hết các khối sẽ không đạt hết công suất trên bất kỳ tài nguyên nào, do đó, một thuật toán đơn giản như chấp nhận bất kỳ giao dịch nào trả đủ phí là đủ.
Hiện tại, chúng tôi có khí đa chiều để thực thi và khối dữ liệu; về nguyên tắc, chúng tôi có thể mở rộng điều này sang nhiều chiều hơn: chẳng hạn như calldata (dữ liệu giao dịch), đọ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 kích thước khí mới dành riêng cho calldata. Đồng thời, nó cũng đơn giản hóa cơ chế Gas đa chiều bằng cách hợp nhất ba loại khí thành một khung (kiểu EIP-4844), từ đó cũng giải quyết được các sai sót toán học của EIP-1559. EIP-7623 là một giải pháp chính xác hơn, giới hạn nghiêm ngặt hơn dữ liệu cuộc gọi tối đa cho các vấn đề tài nguyên ở mức trung bình và trong trường hợp xấu nhất mà không đưa ra một chiều hướng hoàn toàn mới.
Hướng nghiên cứu tiếp theo là giải quyết bài toán tốc độ cập nhật và tìm ra thuật toán tính phí cơ sở nhanh hơn, đồng thời giữ lại bất biến khóa đượ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 chỉ gần với giá trị mục tiêu). ).
Liên kết đến nghiên cứu hiện có
Câu hỏi thường gặp về EIP-1559: Câu hỏi thường gặp về EIP-1559
Phân tích thực nghiệm trên EIP-1559: Phân tích thực nghiệm
Những cải tiến được đề xuất cho phép điều chỉnh nhanh chóng: Những cải tiến được đề xuất
Phần về cơ chế tính phí cơ bản trong Câu hỏi thường gặp về EIP-4844: Câu hỏi thường gặp về EIP-4844
EIP-7706: EIP-7706
EIP-7623: EIP-7623
Khí đa chiều: Khí đa chiều
Những nỗ lực còn lại và sự đánh đổi là gì?
Có hai sự đánh đổi chính đối với Khí đa chiều:
1. Tăng độ phức tạp của giao thức: Việc đưa Gas đa chiều vào sẽ làm cho giao thức trở nên phức tạp hơn.
2. Tăng độ phức tạp của thuật toán tối ưu cần thiết để lấp đầy một khối: Thuật toán tối ưu cần thiết để đưa một khối đạt dung lượng cũng trở nên phức tạp.
Độ phức tạp của giao thức tương đối nhỏ đối với calldata nhưng lại tăng đối với các kích thước khí bên trong EVM (chẳng hạn như đọc và ghi bộ lưu trữ). Vấn đề là không chỉ người dùng đặt giới hạn gas, hợp đồng còn đặt giới hạn khi gọi các hợp đồng khác. Và hiện tại, cách duy nhất họ có thể đặt giới hạn là một chiều.
Một giải pháp đơn giản là làm cho Gas đa chiều chỉ có sẵn 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 thuộc EOF được yêu cầu thanh toán phí cho tất cả các loại Gas khi thực hiện các hoạt động lưu trữ (ví dụ: nếu SLOAD chiếm 0,03% giới hạn gas truy cập lưu trữ khối thì người dùng không thuộc EOF cũng sẽ bị tính phí 0,03% gas thực thi phí giới hạn).
Nghiên cứu thêm về Khí đa chiều sẽ giúp hiểu được những sự đánh đổi này 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 Khí đ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ợ các yêu cầu như cây nhị phân dựa trên hàm băm STARKed. Đặt mục tiêu rõ ràng về 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 dễ dàng hơn.
Như đã đề cập trước đó, sự tồn tại của EOF giúp việc triển khai các phiên bản Khí đa chiều cực đoan hơn trở nên dễ dàng hơn do tính chất Khí không thể quan sát được của nó.
Chức năng trễ có thể kiểm chứng (VDF)
Nó giải quyết được vấn đề gì?
Hiện tại, Ethereum sử dụng tính ngẫu nhiên dựa trên RANDAO để chọn những người đề xuất, 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.
Do đó, mỗi người đề xuất có 1 quyền kiểm soát: họ có thể thay đổi tính ngẫu nhiên bằng cách không xuất hiện (với chi phí phải trả). Cách tiếp cận này có ý nghĩa trong việc tìm kiếm những người đề xuất vì rất hiếm khi bạn từ bỏ một cơ hội và nhận được hai cơ hội mới. Nhưng điều này không lý tưởng cho các ứng dụng trên chuỗi yêu cầu tính ngẫu nhiên. Lý tưởng nhất là chúng ta nên tìm một nguồn ngẫu nhiên mạnh mẽ hơn.
VDF là gì và nó hoạt động như thế nào?
Hàm trễ có thể kiểm chứng là hàm chỉ có thể được đánh giá 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: for i in range( 10** 9): x = hash(x). Kết quả đầu ra, được chứng minh là đúng bằng SNARK, 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 vẫn chưa được biết tại thời điểm T: đầu ra sẽ chỉ có sẵn tại một thời điểm nào đó sau T sau khi ai đó đã chạy xong tính toán. 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 giữ lại kết quả và do đó không có khả năng thao túng kết quả.
Rủi ro chính của chức năng bị trì hoãn có thể xác minh là tối ưu hóa ngẫu nhiên: ai đó thấy mình chạy chức năng nhanh hơn dự kiến, từ đó thao túng thông tin họ tiết lộ tại thời điểm T.
Tối ưu hóa bất ngờ có thể xảy ra theo hai cách:
1. Tăng tốc phần cứng: Ai đó xây dựng một ASIC có thể chạy các vòng tính toán nhanh hơn phần cứng hiện có.
2. Song song hóa ngẫu nhiên: Ai đó tìm ra cách chạy một hàm nhanh hơn bằng cách song song hóa nó, mặc dù làm như vậy đòi hỏi tài nguyê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 duy trì hiệu quả và thiết thực (ví dụ: một vấn đề với các phương pháp tiếp cận dựa trên hàm băm là việc SNARK chứng minh các hàm băm trong thời gian thực đòi hỏi phần cứng nặng). Việc tăng tốc phần cứng thường được giải quyết bởi một bên có lợi ích công cộng tự mình tạo và phân phối VDF ASIC gần như tối ưu.
Liên kết đến nghiên cứu hiện có
Trang web nghiên cứu VDF: vdfresearch.org
Suy nghĩ về các cuộc tấn công vào VDF trong Ethereum, 2018: Suy nghĩ về các cuộc tấn công
Các cuộc tấn công chống lại VDF MinRoot được đề xuất: Các cuộc tấn công chống lại MinRoot
Những nỗ lực còn lại và sự đánh đổi là gì?
Hiện tại, không có cấu trúc VDF nào đáp ứng đầy đủ yêu cầu của các nhà nghiên cứu Ethereum về mọi mặt. Vẫn cần nhiều công việc hơn để tìm ra các chức năng như vậy. Nếu tìm thấy, sự đánh đổi chính là liệu có bao gồm nó hay không: một sự đánh đổi đơn giản giữa chức năng và độ phức tạp của giao thức cũng như rủi ro bảo mật.
Nếu chúng tôi coi VDF là an toàn, nhưng hóa ra nó lại không an toàn, tùy thuộc vào cách nó được triển khai, tính bảo mật sẽ giảm xuống mức giả định RANDAO (1 bit kiểm soát cho mỗi kẻ tấn công) hoặc tệ hơn một chút. Do đó, nếu VDF bị lỗi, nó sẽ không phá vỡ giao thức nhưng sẽ phá vỡ các ứng dụng phụ thuộc nhiều vào nó hoặc bất kỳ tính năng giao thức mới nào.
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 khép kín của giao thức Ethereum, ngoài việc tăng cường bảo mật cho việc lựa chọn người đề xuất, còn có các ứng dụng trong (i) các ứng dụng trên chuỗi dựa vào tính ngẫu nhiên và (ii) nhóm bộ nhớ mật mã, mặc dù dựa trên việc tạo VDF nhóm bộ nhớ được mã hóa vẫn dựa vào những khám phá mật mã bổ sung chưa xảy ra.
Một điểm quan trọng cần nhớ là, khi tính đến những yếu tố không chắc chắn về phần cứng, có một số chênh lệch giữa nhu cầu và việc tạo đầu ra VDF. Đ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 cân nhắc khi hoàn thiện một bể riêng lẻ hoặc một ủy ban lựa chọn thiết kế.
Sự xáo trộn và chữ ký một lần: tương lai xa 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 báo năm 1997 của ông về “Thỏa thuận của Chúa”. Trong bài báo, ông chỉ ra rằng nhiều ứng dụng đa bên 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.
Cho đến nay chúng ta mới chỉ có thể đạt được một phần lý tưởng này. Nếu tất cả những gì chúng ta cần là một máy tính ảo minh bạch mà dữ liệu và tính toán của nó không thể bị tắt, kiểm duyệt hoặc giả mạo và quyền riêng tư không phải là mục tiêu, thì blockchain có thể đạt được mục tiêu này, 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 tôi chỉ có thể phát triển một số 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 danh tính để 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ử kiểu Chaim, 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, chúng ta lần đầu tiên có cái nhìn thoáng qua về một cách tiếp cận khác và mạnh mẽ hơn, một cách tiếp cận dựa trên mật mã có thể lập trình được. Thay vì tạo giao thức mới cho mọi ứng dụng mới, chúng tôi có thể sử dụng các giao thức mới mạnh mẽ—cụ thể 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ữ và bằng chứng (i) dễ 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 cải tiến lớn về cả quyền riêng tư và khả năng mở rộng và tôi ví nó giống như tác động của máy biến áp trong trí tuệ nhân tạo. Hàng nghìn người trong nhiều năm đang ứng tuyển một công việc cụ thể đột nhiên được thay thế bằng giải pháp phù hợp cho tất cả này, giải pháp có thể xử lý hàng loạt vấn đề bất ngờ.
Tuy nhiên, 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ẽ. Những giao thức này mạnh mẽ đến mức khi tôi nghĩ về chúng, chúng khiến tôi nhớ đến một bộ bài rất mạnh mẽ trong Yu-Gi-Oh -- trò chơi bài và chương trình truyền hình mà tôi chơi khi còn nhỏ: Những lá bài Thần Ai Cập.
Các lá bài Thần của Ai Cập là ba lá bài cực kỳ mạnh mẽ, truyền thuyết kể rằng quá trình tạo ra những lá bài này có thể gây chết người và sức mạnh của chúng khiến chúng bị cấm sử dụng trong các trận đấu tay đôi. Tương tự, trong mật mã, chúng ta có bộ ba giao thức thần Ai Cập này:
ZK-SNARK là gì và chúng hoạt động như thế nào?
ZK-SNARK là một trong ba giao thức mà chúng tôi đã có có mức độ hoàn thiện cao hơn. Trong 5 năm qua, những cải tiến đáng kể về tốc độ của người chứng minh và sự thân thiện với nhà phát triển đã biến ZK-SNARK 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 phải có một chủ sở hữu duy nhất phải có mặt để phê duyệt việc đọc hoặc ghi vào trạng thái đó.
Giao thức thứ hai không có giới hạn này là mã hóa đồng hình hoàn toàn (FHE) cho phép bạn thực hiện bất kỳ tính toán 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 các tính toán trên dữ liệu của người dùng vì lợi ích của người dùng trong khi vẫn giữ dữ liệu và thuật toán ở chế độ riêng tư.
Nó cũng cho phép bạn mở rộng các hệ thống bỏ phiếu như MACI để đảm bảo quyền riêng tư và bảo mật gần như hoàn hảo. FHE từ lâu được cho là quá kém hiệu quả để sử dụng trong thực tế, nhưng giờ đây nó cuối cùng đã trở nên đủ hiệu quả để các ứng dụng thực tế bắt đầu xuất hiện.
Cursive là một ứng dụng tận dụng khả năng tính toán của hai bên và mã hóa đồng hình hoàn toàn (FHE) để khám phá lợi ích chung nhằm đảm bảo quyền riêng tư.
Tuy nhiên, 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 bảo vệ thứ hai bằng cách sử dụng Môi trường thực thi đáng tin cậy (TEE), nhưng đây vẫn là một hạn chế.
Tiếp theo là giao thức thứ ba thậm chí còn mạnh hơn sự kết hợp của hai giao thức đầu tiên: che giấu khả năng phân biệt. Mặc dù công nghệ vẫn chưa hoàn thiện nhưng tính đến năm 2020, chúng tôi đã có các 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 triển khai chúng.
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 ý trong khi ẩ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ể ký bất kỳ số nguyên tố nào bằng chương trình này, nhưng không thể trích xuất khóa. Tuy nhiên, khả năng của nó còn vượt xa điều đó: kết hợp 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à hơn thế nữa.
Điều duy nhất mà một obfuscator không thể phân biệt được là ngăn chặn việc sao chép chính nó. Tuy nhiên, đối với vấn đề đó, có một công nghệ mạnh mẽ hơn đang chờ đợi, mặc dù công nghệ này 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.
Bằng cách kết hợp kỹ thuật mã hóa và chữ ký một lần, chúng tôi 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. Mục tiêu duy nhất không thể đạt được chỉ bằng mật mã và vẫn yêu cầu blockchain đảm bảo khả năng chống kiểm duyệt. Những công nghệ này không chỉ giúp Ethereum an toàn hơn mà còn cho phép xây dựng các ứng dụng mạnh mẽ hơn trên nền tảng này.
Để hiểu rõ hơn cách những tính năng cơ bản này bổ sung thêm các khả năng bổ sung, chúng tôi sử dụng biểu quyết làm ví dụ chính. Bỏ phiếu là một vấn đề thú vị vì nó cần đáp ứng một số thuộc tính bảo mật phức tạp, 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 với các đặc tính bảo mật mạnh mẽ đã tồn tại trong nhiều thập kỷ, nhưng chúng ta có thể tự gây khó khăn hơn cho chính mình và yêu cầu các thiết kế có thể xử lý các giao thức bỏ phiếu tùy ý: chẳng hạn như bỏ phiếu bậc hai, cấp vốn bậc hai hạn chế theo cặp, cấp vốn bậc hai phù hợp với cụm, v.v. hãy chờ đợi. Nói cách khác, chúng ta muốn bước đếm là một thủ tục tùy ý.
Đầu tiên, giả sử chúng ta đưa kết quả bỏ phiếu công khai lê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 mọi người bỏ phiếu). Nhưng chúng tôi không có sự riêng tư.
Tiếp theo, chúng tôi đã thêm ZK-SNARK và 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.
Tiếp theo, chúng tôi giới thiệu cơ chế MACI, trong đó các phiếu bầu được mã hóa bằng khóa giải mã của máy chủ trung tâm. Máy chủ trung tâm chịu trách nhiệm về quá 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 kết quả chứng minh ZK-SNARK. Điều này giữ lại sự đảm bảo trước đó (ngay cả khi máy chủ gian lận!), nhưng nó cũng 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 phiếu bầu của mình nhưng họ không thể chứng minh rằng họ không bỏ phiếu để bù đắp cho phiếu bầu đó. Đ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 chạy việc kiểm phiếu trong FHE và sau đó thực hiện các phép tính giải mã ngưỡng N/2-of-N. Điều này làm tăng khả năng đảm bảo khả năng chống cưỡng bức lên N/2-of-N thay vì 1-of-1.
Chúng tôi làm xáo trộn chương trình kiểm phiếu và thiết kế chương trình che giấu để nó chỉ có thể đưa ra kết quả khi được ủy quyền. Phương thức ủy quyền có thể là bằng chứng về sự đồng thuận của blockchain, một số loại bằng chứng công việc hoặc kết hợp cả hai. Điều này làm cho việc đảm bảo chống ép buộc gần như hoàn hảo: trong trường hợp đồng thuận blockchain, 51% người xác thực cần thông đồng để bẻ khóa; trong trường hợp bằng chứng công việc, ngay cả khi mọi người thông đồng, phiếu bầu sẽ được tính lại; với các tập hợp cử tri khác nhau để thử. Hành động thu hút các cá nhân cử tri cũng sẽ cực kỳ 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 nhỏ ngẫu nhiên đối với số phiếu bầu cuối cùng để tăng thêm khó khăn trong việc trích xuất hành vi của từng cử tri.
Chúng tôi đã thêm chữ ký một lần, một chữ ký 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 cho một loại thông tin cụ thể. Điều này làm cho việc đảm bảo chống lực thực sự hoàn hảo.
Khả năng che giấu không thể phân biệt được cũng hỗ trợ các ứng dụng mạnh mẽ khác. Ví dụ:
1. Các tổ chức tự trị phi tập trung (DAO), đấu giá trực tuyến và các ứng dụng khác có trạng thái bí mật nội bộ tùy ý.
2. Một thiết lập thực sự đáng tin cậy thực sự phổ biến: 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, đặt hàm băm (khóa, chương trình) làm đầu vào cho chương trình. Với một chương trình như vậy, bất kỳ ai cũng có thể đưa Chương trình 3 vào chính nó, kết hợp các khóa được mã hóa trước của chương trình với khóa riêng của họ, do đó mở rộng quá trình thiết lập. Điều này có thể được sử dụng để tạo thiết lập đáng tin cậy 1/N cho bất kỳ giao thức nào.
3. Việc xác minh ZK-SNARK chỉ yêu cầu chữ ký: Việc thực hiện việc này rất đơn giản: Thiết lập một môi trường đá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 khóa nếu có ZK-SNARK hợp lệ.
4. Nhóm bộ nhớ được mã hóa: Việc mã hóa các giao dịch trở nên rất đơn giản, do đó các giao dịch chỉ có thể được giải mã khi một sự kiện trên chuỗi nhất định xảy ra trong tương lai. Điều này thậm chí có thể bao gồm các Chức năng trì hoãn có thể xác minh (VDF) thực thi thành công.
Với chữ ký một lần, chúng tôi có thể làm cho blockchain miễn nhiễm với các cuộc tấn công 51% đối với việc đảo ngược tài chính, mặc dù các cuộc tấn công kiểm duyệt vẫn có thể xảy ra. Những nguyên tắc cơ bản như chữ ký một lần khiến tiền lượng tử trở nên khả thi, giải quyết vấn đề chi tiêu gấp đôi mà không cần chuỗi khối, mặc dù nhiều ứng dụng phức tạp hơn vẫn yêu cầu chuỗi.
Nếu những nguyên thủy này có thể được thực hiện đủ 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 sẽ là việc xác minh tính đúng đắn của việc triển khai.
Dưới đây là các liên kết đến một số nghiên cứu hiện có:
1. Giao thức che giấu khả năng phân biệt (2021): Giao thức che giấu khả năng phân biệt
2. Làm xáo trộn có thể giúp ích cho Ethereum như thế nào: Làm xáo trộn có thể giúp ích cho Ethereum như thế nào
3. Cấu trúc chữ ký một lần đầu tiên được biết đến: Cấu trúc chữ ký một lần đầu tiên được biết đến
4. Đã cố gắng thực hiện việc che giấu (1): Đã cố gắng thực hiện việc che giấu (1)
5. Đã cố gắng thực hiện việc che giấu (2): Đã cố gắng thực hiện việc che giấu (2)
Những công việc nào còn phải làm và sự đánh đổi là gì?
Vẫn còn rất nhiều việc phải làm, tính năng che giấu 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ạy chậm một cách đáng ngạc nhiên (nếu không muốn nói là nhiều hơn) để hữu ích trong các ứng dụng. Sự nhầm lẫn không thể phân biệt được được biết là cần có thời gian đa thức lý thuyết, nhưng trong các ứng dụng thực tế, nó có thể chạy lâu hơn thời gian tồn tại của vũ trụ. Các giao thức gần đây đã cho thấy một số cải tiến về thời gian chạy, nhưng chi phí vẫn cò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í còn chưa tồn tại: tất cả cấu trúc bạn thấy trên internet đều là nguyên mẫu không thể thực hiện nhiều hơn 4 bit hoặc chúng hoàn toàn không phải là máy tính lượng tử và mặc dù chúng có thể có các bộ phận lượng tử, nhưng chúng không thể chạy những thứ như thuật toán của Shor Hoặc các phép tính có ý nghĩa như 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 xa nữa. Tuy nhiên, ngay cả khi máy tính lượng tử thực sự sớm xuất hiện, một người bình thường sử dụng máy tính lượng tử trên máy tính xách tay hoặc điện thoại của họ vẫn có thể phải đợi hàng thập kỷ trước khi các tổ chức quyền lực có thể giải mã được mật mã đường cong elip.
Đối với khả năng che giấu không thể phân biệt được, sự cân bằng quan trọng nằm ở giả định về bảo mật và có những thiết kế cấp tiến hơn sử dụng các giả định đặc biệt. Những thiết kế này thường có thời gian chạy thực tế hơn, nhưng những giả định đặc biệt đôi khi bị phá vỡ. Theo thời gian, chúng ta có thể hiểu rõ hơn về mạng tinh thể, cho phép chúng ta hình thành các giả thuyết không dễ bị phá vỡ. Tuy nhiên, con đường này có nhiều rủi ro 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 giảm xuống mức giả định 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 tôi có được 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ật mã cực mạnh có thể cách mạng hóa trò chơi, chẳng hạn như:
1. Nếu chúng tôi nhận được ZK-SNARK dễ xác minh như chữ ký thì chúng tôi có thể không cần bất kỳ giao thức tổng hợp nào nữa; chúng tôi có thể xác minh chúng trực tiếp trên chuỗi.
2. Chữ ký một lần có thể có nghĩa là giao thức bằng chứng cổ phần an toàn hơn.
3. Nhiều giao thức bảo mật phức tạp có thể chỉ cần được thay thế bằng Máy ảo Ethereum (EVM) bảo vệ quyền riêng tư.
4. Nhóm bộ nhớ được mã hóa trở nên dễ thực hiện hơn.
Ban đầu, lợi ích sẽ xảy ra ở lớp ứng dụng, vì L1 của Ethereum vốn cần phải thận trọng trong các giả định bảo mật của nó. Tuy nhiên, việc sử dụng riêng lớp ứng dụng có thể gây gián đoạn, như trường hợp xuất hiện của ZK-SNARK.
