Được viết bởi: Vitalik Buterin

Biên soạn bởi: Yangz, Techub News

Có rất nhiều "điểm nhấn 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 nhưng lại không phù hợp với một danh mục con lớn hơn. Trong thực tế, khoảng một nửa nội dung nói về các cải tiến EVM khác nhau và phần còn lại nói về các chủ đề thích hợp khác nhau. Bài viết này sẽ khám phá chủ đề này.

Lộ trình của The Splurge, 2023 Các mục tiêu chính của The Splurge:

EVM hiện tại 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ó cực kỳ kém hiệu quả, gây khó khăn cho việc triển khai nhiều dạng kỹ thuật mã hóa 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.

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 giới thiệu trong đợ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 nhiều tính năng đáng chú ý, trong đó nổi bật nhất bao gồm:

Khung mã EOF Mặc dù các hợp đồng kế thừa cuối cùng có thể không được dùng nữa (và thậm chí có thể bị buộc phải sử dụng mã EOF), các hợp đồng kế thừa sẽ tiếp tục tồn tại và có thể được tạo. Các hợp đồng mới sẽ được hưởng lợi từ những cải tiến hiệu quả do EOF mang lại, bao gồm mã byte nhỏ hơn một chút do chức năng của chương trình, cũng như các tính năng mới dành riêng cho EOF hoặc giảm chi phí gas độc đáo của nó. Với sự ra đời của EOF, việc nâng cấp thêm sẽ trở nên dễ dàng hơn. Phiên bản hoàn chỉnh 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 mà các opcode khác không thể truy cập được. Bằng cách này, các phép toán tối ưu hóa như phép nhân Montgomery có thể được sử dụng. Một ý tưởng mới hơn là kết hợp EVM-MAX với chức năng đa dữ liệu lệnh đơn (SIMD). SIMD đã tồn tại như một thiết kế nhỏ trong Ethereum trong một thời gian dài, bắt đầu với EIP-616 của Greg Colvin . SIMD có thể được sử dụng để tăng tốc nhiều dạng thuật toán mã hóa, bao gồm hàm băm, STARK 32 bit và mật mã mạng. EVM-MAX và SIMD là sự kết hợp tự nhiên giữa các tiện ích mở rộng hướng đến hiệu suất cho EVM. Ý tưởng thiết kế chung của EIP kết hợp là lấy EIP-6690 làm điểm bắt đầu, sau đó:

Điều này đủ để thực hiện nhiều dạng thuật toán mã hóa, bao gồm mã hóa đường cong elip, mã hóa miền nhỏ (như Poseidon, STARK vòng tròn), hàm băm truyền thống (như SHA256, KECCAK, BLAKE) và mật mã mạng. Tất nhiên, những nâng cấp EVM khác là có thể, nhưng cho đến nay chúng ít được chú ý hơn.

Điều này đủ để thực hiện nhiều dạng thuật toán mã hóa, bao gồm mã hóa đường cong elip, mã hóa miền nhỏ (như Poseidon, STARK vòng tròn), hàm băm truyền thống (như SHA256, KECCAK, BLAKE) và mật mã mạng. Tất nhiên, những nâng cấp EVM khác là có thể, nhưng cho đến nay chúng ít được chú ý hơn.

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ó khả năng một kế hoạch sẽ bị loại bỏ (đã có trường hợp kế hoạch bị loại bỏ khỏi hard fork vào phút cuối trước đó), 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 đối với EVM sẽ không yêu cầu 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 với EVM là độ phức tạp L1 so với độ phức tạp của cơ sở hạ tầng. Việc thêm EOF vào triển khai EVM yêu cầu nhiều mã và việc kiểm tra mã tĩnh khá phức tạp. Tuy nhiên, đổi lại, chúng ta có thể đơn giản hóa ngôn ngữ cấp cao, đơn giản hóa việc triển khai EVM và đạt được các lợi ích khác. Hãy nói theo cách này, 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 dựa trên EOF. Một trong những nhiệm vụ quan trọng là triển khai các chức năng tương tự như EVM-MAX cộng với SIMD và tiến hành kiểm tra điểm chuẩn về lượng gas tiêu thụ cho các hoạt động mã hóa khác nhau.

Sau khi L1 điều chỉnh EVM, L2 có thể sao chép dễ dàng hơn. Một bên điều chỉnh và một bên không điều chỉnh có thể dẫn đến không tương thích, điều này cũng có nhược điểm riêng. Ngoài ra, EVM-MAX cộng với SIMD có thể giảm chi phí gas của nhiều hệ thống xác minh, từ đó cải thiện hiệu suất L2. Việc thay thế mã được biên dịch trước bằng mã EVM có thể không ảnh hưởng lớn đến hiệu quả, nhưng nó sẽ thực hiện cùng một nhiệm vụ, giúp loại bỏ nhiều mã được biên dịch trước hơn dễ dàng hơn.

Ngày nay, các giao dịch chỉ có thể được xác minh một cách, đó là chữ ký ECDSA. Mục đích ban đầu của việc trừu tượng hóa tài khoản là mở rộng trên cơ sở này để logic xác minh tài khoản có thể là bất kỳ mã EVM nào. Điều này cho phép một loạt các ứng dụng bao gồm:

Kể từ khi việc trừu tượng hóa tài khoản bắt đầu vào năm 2015, các mục tiêu này đã mở rộng thành một tập hợp lớn các "mục tiêu tiện lợi", chẳng hạn như một tài khoản không có ETH nhưng các mã thông báo ERC20 khác có thể sử dụng các mã thông báo này để trả phí gas. Hình dưới đây là tóm tắt các mục tiêu này:

MPC đề cập đến tính toán 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 hợp nhất trực tiếp các phần khóa. EIP-7702 là EIP dự kiến ​​được giới thiệu trong đợt hard fork tiếp theo và là một phần trong nhận thức ngày càng tăng về nhu cầu cho phép tất cả người dùng, bao gồm cả người dùng EOA, tận hưởng sự tiện lợi của việc trừu tượng hóa tài khoản để cải thiện trải nghiệm người dùng trong thời gian ngắn. Và tránh kết quả chia 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 bên ngoài, 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à về "sự 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ệ gia tăng như EIP-7702, nhưng hầu hết các mục tiêu bảo mật đã thúc đẩy đề xuất trừu tượng hóa tài khoản ban đầu. được giải quyết bằng cách quay lại và giải quyết vấn đề ban đầu, đó là cho phép mã hợp đồng thông minh kiểm soát việc xác minh giao dịch. Điều này vẫn chưa được thực hiện vì việc đạt được điều này một cách an toàn vẫn còn là một thách thức.

Cốt lõi của việc trừu tượng hóa tài khoản là cho phép các hợp đồng thông minh thay vì chỉ EOA bắt đầu giao dịch và sự phức tạp đến từ cách triển khai điều này theo cách có lợi cho việc duy trì mạng lưới phi tập trung và chống lại các cuộc tấn công từ chối dịch vụ. Các vấn đề về xác thực đa dạng là một thách thức chính:

Giả sử có 1000 tài khoản có chức năng xác minh đều phụ thuộc vào một giá trị duy nhất S và các giao dịch trong mempool đều hợp lệ theo giá trị hiện tại của S Sau đó, một giao dịch lật ngược giá trị của S sẽ làm mất hiệu lực tất cả các giao dịch khác trong mempool. Bằng cách này, kẻ tấn công có thể gửi thư rác tới mempool với chi phí rất thấp và làm tắc nghẽn tài nguyên nút trên mạng. Trong những năm qua, chúng tôi đã nỗ lực làm việc để mở rộng chức năng đồng thời hạn chế rủi ro DoS và cuối cùng chúng tôi đã đạt được sự đồng thuận về cách đạt được "sự trừu tượng hóa tài khoản lý tưởng" và đề xuất ERC-4337.

ERC-4337 chia quá trình xử lý thao tác của người dùng thành hai giai đoạn, đó là 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, thao tác của người dùng sẽ chỉ được chấp nhận nếu giai đoạn xác minh của thao tác người dùng chỉ liên quan đến tài khoản của chính nó và không đọc các biến môi trường. Điều này ngăn chặn các cuộc tấn công xác minh nhiều lần và cũng thực thi các giới hạn gas nghiêm ngặt ở bước xác minh. ERC-4337 được thiết kế như một tiêu chuẩn ngoài giao thức (ERC) vì vào thời điểm đó, các nhà phát triển ứng dụng khách Ethereum đang bận rộn với việc Hợp nhất và không có năng lực rảnh rỗi để phát triển các tính năng khác. Và đây là lý do tại sao ERC-4337 sử dụng thao tác của người dùng làm đối tượ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 cần phải kết hợp ít nhất một số tính năng được đề xuất trong ERC-4337 vào giao thức. Hai lý do chính là:

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

Vấn đề chính còn lại cần giải quyết là làm thế nào để đưa đầy đủ tính năng trừu tượng hóa tài khoản vào giao thức. Một trong những giải pháp phổ biến hơn gần đây là EIP-7701, nhằm mục đích đạt được sự trừu tượng hóa tài khoản dựa trên EOF. Nghĩa là, tài khoản có thể đặt một đoạn mã riêng để xác minh. Nếu tài khoản đặt đoạn mã này thì trong bước xác minh. giao dịch tài khoản Mã sẽ được thực thi.

Cấu trúc mã EOF EIP-7701 cho các tài khoản Điểm hay của phương pháp này là nó cho thấy rõ rằng có hai cách tương đương để xem phần trừu tượng hóa tài khoản cục bộ:

Nếu chúng tôi hạn chế nghiêm ngặt độ phức tạp của mã thực thi trong quá trình xác minh ngay từ đầu (không cho phép truy cập vào trạng thái bên ngoài hoặc thậm chí hạn chế lượng gas quá thấp ngay từ đầu để hữu ích cho các ứng dụng bảo vệ quyền riêng tư hoặc kháng lượng tử), thì điều này Tính bảo mật của phương pháp này là rõ ràng ngay lập tức: nó chỉ đơn giản thay thế xác minh ECDSA bằng việc thực thi mã EVM mất một 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 những hạn chế này, vì cả hai điều quan trọng là 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ử. Để 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 các bước xác minh trở nên cực kỳ tối giản. Sự đánh đổi chính dường như là giữa việc chấp nhận điều gì đó ít thỏa mãn càng nhanh càng tốt so với việc chờ đợi lâu hơn và có lẽ nhận được một giải pháp lý tưởng hơn. Giải pháp lý tưởng rất có thể sẽ là một loại hybrid nào đó. Một cách tiếp cận kết hợp sẽ là kết hợp một số trường hợp sử dụng nhanh hơn, để lại nhiều thời gian hơn để giải quyết những trường hợp khác. Một tùy chọn khác là triển khai phiên bản trừu tượng hóa tài khoản trên L2 trước. Tuy nhiên, thách thức với điều này là để nhóm L2 sẵn sàng nỗ lực áp dụng đề xuất, họ phải tin tưởng rằng L1 và/hoặc các L2 khác sẽ áp dụng các phiên bản tương thích sau này. 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 , có thể 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, đồng thời cũ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 điều này một cách hiệu quả, L2 có thể cần hỗ trợ các opcode như L1SLOAD hoặc REMOTESTATICCALL và cũng có thể cần hỗ trợ từ việc triển khai tính năng trừu tượng hóa tài khoản trên L2.

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

EIP-1559 đã được kích hoạ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, việc triển khai EIP-1559 hiện tại có những sai sót ở các khía cạnh sau:

Tuy nhiên, việc triển khai EIP-1559 hiện tại có những sai sót ở các khía cạnh sau:

Giải pháp sau này cho Blobs ( EIP-4844 ) được thiết kế rõ ràng để 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. Vì vậy, hiện trạng là tình trạng khó hiểu của hai cơ chế khác nhau, thậm chí có khả nă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 sai sót 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. Một trong những 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, đó là việc định giá tài nguyên của Ethereum phải được thiết lập để xử lý trường hợp xấu nhất, tức là toàn bộ lượng gas tiêu thụ của một khối chiếm một tài nguyên, nhưng mức trung bình trường hợp sử dụng ít hơn nhiều. Điều này dẫn đến hiệu quả thấp.

Khí đa chiều là giải pháp cho những sự thiếu hiệu quả này, đặ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. Nếu không có EIP-1559, làm thế nào để tối ưu hóa việc đóng gói một khối với nhiều hạn chế về tài nguyên sẽ là một bài toán “ba lô” phức tạp đa chiều . Với EIP-1559, hầu hết các khối sẽ không hoạt động hết công suất 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ỳ giao dịch nào trả đủ phí" sẽ đủ. Ngày nay, chúng tôi có thiết lập khí đa chiều về thực thi và các đốm màu và 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, bao gồm 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 thứ nguyên khí mới cho calldata. Đồng thời, nó cũng đơn giản hóa cơ chế khí đa chiều để cả ba loại khí đều thuộc một khung (kiểu EIP-4844), từ đó 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 triệt để 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 bằng cách đặt giới hạn chặt chẽ hơn đối với 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 khác là giải quyết vấn đề về tốc độ cập nhật và tìm ra thuật toán tính phí cơ bản nhanh hơn trong khi vẫn giữ nguyên bất biến khóa được đưa ra bởi cơ chế EIP-4844 (nghĩa 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).

Khí đa chiều có hai nhược điểm chính:

Đối với calldata, độ phức tạp của giao thức là một vấn đề tương đối nhỏ, nhưng đối với kích thước khí "bên trong EVM" (chẳng hạn như đọc và ghi bộ lưu trữ), nó trở thành một vấn đề lớn hơn. Khó khăn là không chỉ người dùng đặt ra gas limit mà hợp đồng cũng đặt ra giới hạn khi gọi các hợp đồng khác. Bây giờ, cách duy nhất họ có thể đặt giới hạn là một chiều. Một cách đơn giản để giải quyết vấn đề này là gas đa chiều chỉ có thể được sử dụng 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 trả 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 phí cho SLOAD là 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% số tiền thực hiện giới hạn khí). Nghiên cứu thêm về khí đa chiều sẽ giúp hiểu được sự cân bằng và xác định sự cân bằng lý tưởng.

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 một số trường hợp "xấu nhất" nhất định, từ đó giảm bớt áp lực tối ưu hóa hiệu suất để hỗ trợ cây nhị phân băm dựa trên STARK. Đặ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à dự đoán nhu cầu trong tương lai dễ dàng hơn. Như đã đề cập ở trên, vì EOF có những đặc tính không thể quan sát được của khí nên nó có thể tạo ra các phiên bản khí đa chiều khắc nghiệt hơn dễ thực hiện hơn.

Hiện tại, Ethereum sử dụng tính ngẫu nhiên dựa trên RANDAO để chọn 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” và 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 người đề xuất vì hiếm khi từ bỏ một đề xuất và nhận cho mình hai đề xuất mới. 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 không phù hợp. 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.

Hàm độ trễ có thể xác minh (VDF) là một hàm chỉ có thể được tính toán tuần tự và không thể 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 toán for i in range(10**9): x = hash(x) . Với bằng chứng về tính chính xác của SNARK, đầu ra có thể được sử dụng làm giá trị ngẫu nhiên. Ý tưởng là các đầ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 biết sau một thời gian T, khi ai đó thực hiện đầy đủ tính toán. Vì bất kỳ ai cũng có thể thực hiện các phép tính nên không thể giữ lại kết quả và do đó không thể thao túng chúng. Rủi ro chính với các chức năng trì hoãn có thể kiểm chứng là sự tối ưu hóa không mong muốn. Nếu ai đó phát hiện ra cách chạy một hàm nhanh hơn nhiều so với dự kiến, thì thông tin họ tiết lộ tại thời điểm T có thể bị thao túng dựa trên kết quả đầu ra trong tương lai. Tối ưu hóa bất ngờ có thể xảy ra theo hai cách:

Tạo ra một VDF thành công là tránh được cả hai vấn đề này 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à bằng chứng SNARK thời gian thực đòi hỏi rất nhiều về phần cứng. 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.)

Hiện tại, chưa 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ẫn còn rất nhiều việc phải làm để tìm ra một chức năng như vậy. Và nếu chúng tôi tìm thấy cấu trúc VDF hoàn hảo thì sự đánh đổi chính là 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 ta coi VDF là an toàn, nhưng hóa ra nó lại không an toàn, thì tùy thuộc vào cách nó được triển khai, tính bảo mật sẽ giảm xuống giả định RANDAO (mỗi kẻ tấn công chỉ có thể thao túng 1 bit) hoặc tệ hơn. Do đó, ngay cả khi VDF gặp sự cố, nó sẽ không phá vỡ giao thức mà 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 VDF.

VDF là một thành phần tương đối độc lập của giao thức Ethereum 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ũng có thể được sử dụng cho các ứng dụng trên chuỗi dựa vào tính ngẫu nhiên, cũng như các mempool được mã hóa. Tuy nhiên, các bộ nhớ mật mã dựa trên VDF vẫn dựa vào các khám phá mật mã bổ sung chưa xảy ra. Một điều cần lưu ý là do sự không chắc chắn về phần cứng, sẽ có một số "khoảng cách" giữa thời điểm đầu ra VDF được tạo và thời điểm đưa đầu ra đó vào. Điều này có nghĩa là thông tin cần phải được lấy trước nhiều khối. Đây có thể là một mức giá phải trả có thể chấp nhận được nhưng cần được cân nhắc trong các thiết kế như quyết toán một vị trí hoặc lựa chọn ủy ban.

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 này, ông chỉ ra rằng các ứng dụng nhiều 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ự tin tưởng vào bất kỳ tác nhân cụ thể nào.

"Các giao thức đáng tin cậy về mặt toán học" của Nick Szabo Cho đến nay, chúng ta mới chỉ gần đạ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 (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) và 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ế. Nhưng nếu quyền riêng tư là một trong những mục tiêu thì cho đến gần đây, chúng ta chỉ có thể có một số giao thức cụ thể cho các ứng dụng cụ thể, chẳng hạn như chữ ký số để xác thực cơ bản, chữ ký vòng và chữ ký vòng có thể xâu chuỗi để ẩn danh thô, mã hóa dựa trên danh tính (để cho phép nhiều hơn nữa). mã hóa thuận tiệ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 nỗ lực cho mỗi ứng dụng mới. Vào những năm 2010, lần đầu tiên chúng ta thấy một cách tiếp cận khác mạnh mẽ hơ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 ta có thể sử dụng các giao thức mới mạnh mẽ (đặc biệt là ZK-SNARK) để thêm đả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 xác nhận quyền sở hữu tùy ý về dữ liệu họ nắm giữ theo cách dễ xác minh và không tiết lộ bất kỳ dữ liệu nào ngoài chính xác nhận quyền sở hữu đó. Đây là một bước tiến lớn về quyền riêng tư và khả năng mở rộng đồng thời, và theo tôi, nó giống như máy biến áp của Google trong lĩnh vực trí tuệ nhân tạo. Hàng ngàn năm các vấn đề dành riêng cho ứng dụng đột nhiên có một giải pháp phổ quát mà chúng ta có thể áp dụng để giải quyết tất cả các loại vấn đề khó chịu. Hơn nữa, 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 bất cứ khi nào tôi nghĩ về chúng, tôi lại nhớ đến bộ bài Các vị thần Ai Cập cực kỳ mạnh mẽ từ thời thơ ấu của tôi Yu-Gi-Oh! (mạnh đến mức nó 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ũng có “Thỏa thuận ba vị thần”: ZK-SNARK, Mã hóa hoàn toàn đồng hình (FHE) và Obfuscation.

Chúng tôi đã phát triển ZK-SNARK ở mức độ hoàn thiện cao. Trong 5 năm qua, tốc độ của người chứng minh và sự thân thiện với nhà phát triển đã được cải thiện đáng kể và 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. Tuy nhiên, ZK-SNARK có một hạn chế quan trọng, đó là dữ liệu cần phải được biết để 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" và "chủ sở hữu" này phải có khả năng 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, nó là mã hóa đồng cấu hoàn toàn (FHE). FHE cho phép mọi tính toán được thực hiện trên dữ liệu được mã hóa mà không cần xem dữ liệu. Bằng cách này, việc tính toán có thể được thực hiệ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 có thể mở rộng các hệ thống bỏ phiếu như MACI với sự đảm bảo về quyền riêng tư và bảo mật gần như hoàn hảo. FHE luôn bị chỉ trích là quá kém hiệu quả đối với các ứng dụng thực tế, nhưng giờ đây nó đã trở nên đủ hiệu quả và các ứng dụng phù hợp đã xuất hiện.

Cursive là một ứng dụng sử dụng điện toán hai bên và FHE để khám phá những lợi ích chung và bảo vệ quyền riêng tư. Tuy nhiên, FHE cũng có những hạn chế. Bất kỳ công nghệ nào dựa trên FHE vẫn cần có người giữ chìa khóa. Phương pháp giữ khóa có thể là thiết lập phân tán M-of-N hoặc thậm chí có thể sử dụng TEE để thêm lớp phòng thủ thứ hai, nhưng nó vẫn là một hạn chế. Và điều này cũng dẫn đến giao thức thứ ba, làm xáo trộn tính không thể phân biệt được . Mặc dù giao thức này vẫn chưa hoàn thiện nhưng tính đến năm 2020, chúng tôi đã 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à việc triển khai gần đây đã bắt đầu . Tính năng che giấu không thể phân biệt được cho phép tạo ra một "chương trình được mã hóa" thực hiện các phép tính tùy ý, do đó ẩ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ố, sau đó phân phối chương trình cho người khác. Những người này sau đó có thể sử dụng chương trình để ký bất kỳ số nguyên tố nào nhưng không thể lấy được khóa. Tất nhiên, khả năng che giấu không thể phân biệt được vượt xa điều này và cùng với các thuật toán 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í hơn thế nữa. Điều duy nhất mà một chương trình bị xáo trộn không thể làm là ngăn chặn việc sao chép chính nó. Nhưng đối với điều này, một thứ thậm chí còn mạnh mẽ hơn sẽ xuất hiện: chữ ký lượng tử một lần, giả sử mọi người đều có máy tính lượng tử.

Với tính năng mã hóa và 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ỉ với mật mã và điều mà chúng ta vẫn cần blockchain để đạt được, đó là đảm bảo khả năng chống kiểm duyệt. Những công nghệ này sẽ 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 đó. Để hiểu những thứ nguyên thủy này được trao quyền như thế nào, chúng ta có thể hiểu rõ hơn qua ví dụ về "bỏ phiếu". Bỏ phiếu là một chủ đề thú vị cần đáp ứng một số đặ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 có đặc tính bảo mật mạnh đã tồn tại trong nhiều thập kỷ, nhưng nếu chúng ta cần một 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 giới hạn theo cặp , cấp vốn bậc hai phù hợp với cụm, v.v. thì chúng ta hy vọng rằng bước "kiểm phiếu" sẽ là một thủ tục tùy ý:

Khả năng che giấu không thể phân biệt được cũng cho phép các ứng dụng mạnh mẽ khác. Ví dụ:

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 đả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. Các nguyên tắc tương tự như chữ ký một lần có thể trao quyền cho tiền lượng tử và giải quyết vấn đề chi tiêu gấp đôi mà không cần blockchain, mặc dù nhiều ứng dụng phức tạp hơn vẫn yêu cầu blockchain. Nếu những thứ nguyên thủy này có thể được tạo ra đủ hiệu quả thì hầu hết các ứng dụng trên thế giới đều có thể được phân quyền. Nút thắt chính là việc xác minh tính đúng đắn của việc triển khai.

Trước hết, sự phát triển của công nghệ obfuscation không thể phân biệt được là cực kỳ non nớt. Tốc độ phát triển của các cấu trúc ứng cử viên chậm hơn hàng triệu lần so với ứng dụng và hoàn toàn không thể sử dụng được. 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 thực tế chạy trong thời gian dài hơn thời gian tồn tại của vũ trụ. Mặc dù các giao thức gần đây đã làm cho thời gian chạy ít khắc nghiệt hơn nhưng chi phí hoạt động vẫn quá cao để sử dụng thường xuyên. Hơn nữa, máy tính lượng tử thậm chí còn không tồn tại. Tất cả các cấu trúc mà chúng ta có thể đọc trên internet hiện 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 chúng không phải là máy tính lượng tử thực sự vì mặc dù chúng có thể có các thành phần lượng tử nhưng chúng không thể chạy 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 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 thì ngày mà người dân 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 rất có thể sẽ là điều này. diễn ra nhiều thập kỷ sau khi các tổ chức hùng mạnh mua lại máy tính lượng tử có khả năng phá vỡ mật mã đường cong elip. Để có được sự xáo trộn không thể phân biệt được, sự đánh đổi quan trọng là giả định về bảo mật. Có một số thiết kế cấp tiến hơn sử dụng các giả định kỳ lạ. Thời gian chạy của những thiết kế này nhìn chung thực tế hơn, nhưng những giả định cụ thể này cuối cùng có thể bị phá vỡ . Theo thời gian, cuối cùng chúng ta có thể tìm hiểu đủ về mật mã mạng để đưa ra những giả định không thể bị phá vỡ. Tuy nhiên, con đường này rủi ro hơn. Một cách tiếp cận thận trọng hơn sẽ là gắn bó với các giao thức có độ bảo mật có thể giảm xuống theo cá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 để có được một giao thức chạy đủ nhanh.

Công nghệ mã hóa cực kỳ mạnh mẽ có thể thay đổi hoàn toàn cuộc chơi. Ví dụ:

Ban đầu, lớp ứng dụng sẽ được hưởng lợi rất nhiều vì bản thân Ethereum L1 cần tuân thủ các giả định về bảo mật. Tuy nhiên, chỉ riêng việc sử dụng lớp ứng dụng có thể là yếu tố thay đổi cuộc chơi, cũng như sự xuất hiện của ZK-SNARK.