Tương lai có thể có của giao thức Ethereum(6): The Splurge

Có kế hoạch tối ưu hóa hơn nữa giao thức Ethereum để cải thiện hiệu quả và tính bền vững của mạng. Nó có thể không chỉ vượt qua các nút thắt kỹ thuật mà còn được kỳ vọng sẽ cách mạng hóa tính bảo mật và quyền riêng tư blockchain.

Văn bản gốc: Tương lai có thể có của giao thức Ethereum, phần 6: The Splurge (vitalik.eth)

Tác giả: Vitalik.eth

Biên soạn bởi: Yewlne, LXDAO

Bìa: Thiên hà

Lời nói đầu của người dịch

Ngày nay, với sự phát triển nhanh chóng của công nghệ blockchain, độ phức tạp của kiến ​​trúc hệ thống ngày càng tăng cao, mang đến những thách thức mới cho cả nhà phát triển và người dùng. Kế hoạch "The Splurge" nhấn mạnh đến việc nâng cao hiệu quả và tính bền vững của mạng bằng cách tối ưu hóa và hoàn thiện các chi tiết của các giao thức hiện có. Việc khám phá những công nghệ tiên tiến này không chỉ được kỳ vọng sẽ giải quyết các nút thắt kỹ thuật hiện tại mà còn có thể thay đổi hoàn toàn cơ chế bảo mật và quyền riêng tư của blockchain, đưa nó đến gần hơn với trạng thái lý tưởng là “không cần sự tin cậy”. Tôi hy vọng bản dịch lần có thể giúp nhiều độc giả Trung Quốc hơn hiểu được tiến triển mới nhất trong giao thức Ethereum và kích thích sự quan tâm của mọi người đối với những chủ đề quan trọng nhưng thường bị bỏ qua này.

Tổng quan về bài viết này

Bài viết này tổng cộng khoảng 10.000 từ và có 5 phần. Ước tính sẽ mất 55 phút để đọc xong bài viết này.

• Cải tiến EVM
• Trừu tượng hóa tài khoản
• Cải tiến EIP-1559
• Chức năng trễ có thể kiểm chứng (VDF)
• Làm xáo trộn và chữ ký một lần: tương lai của mật mã

Nội dung văn bản

"Tương lai có thể có của Giao thức Ethereum(6): Sự phô trương"

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

Một số thứ rất khó để xếp vào một danh mục duy nhất. Có rất 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 nhưng khó có thể phân loại gọn gàng thành các danh mục con lớn hơn. Trong thực tế, khoảng một nửa trong đó số đó đề cập đến các dạng cải tiến EVM khác nhau, phần còn lại đề cập đến các chủ đề thích hợp khác nhau. Đây là mục tiêu của việc nâng cấp"Splurge".

Sự phô trương: Mục tiêu chính

• Khởi động EVM về "trạng thái kết thúc" ổn định và hiệu quả.
• Việc đưa Trừu tượng hóa tài khoản vào lớp giao thức cho phép tất cả người dùng được hưởng lợi từ các tài khoản an toàn hơn và thuận tiện hơn.
• Tối ưu hóa mô hình kinh tế phí giao dịch để giảm thiểu rủi ro đồng thời cải thiện mở rộng .
• Khám phá các kỹ thuật mã hóa tiên tiến có thể giúp Ethereum tốt hơn về lâu dài.

Nội dung của chương này :

• Cải tiến EVM
• Trừu tượng hóa tài khoản
• Cải tiến EIP-1559
• Chức năng trễ có thể kiểm chứng (VDF)
• Làm xáo trộn và chữ ký một lần: tương lai của mật mã

Cải tiến EVM

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

EVM hiện tại khó thực hiện 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 mã chính thức và mở rộng sau này. Ngoài ra, do tính kém hiệu quả nên rất khó thực hiện nhiều hoạt động mã hóa 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 giới thiệu trong lần hard fork tiếp theo. EOF chứa sê-ri Đề án EIP xác Đề án phiên bản mới của định dạng mã cho EVM với các tính năng chính sau:

• Đạt được 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)
• Vô hiệu hóa cơ chế nhảy động và chỉ giữ lại các bước nhảy tĩnh
• Mã EVM sẽ không thể lấy được thông tin liên quan đến gas
• Đã thêm cơ chế gọi chương trình con rõ ràng

Các phiên bản hợp đồng cũ hơn sẽ tiếp tục được sử dụng và được phép tạo, nhưng các phiên bản hợp đồng cũ hơn có thể bị loại bỏ dần trong tương lai (thậm chí chúng có thể bị buộc phải chuyển đổi sang định dạng EOF). Phiên bản mới của hợp đồng có thể tận dụng những cải tiến về hiệu quả do EOF mang lại: một mặt, nó có thể giảm một chút kích thước mã byte thông qua tính năng chương trình con và mặt khác, nó cũng có thể được hưởng lợi từ các tính năng mới độc đáo và gas thấp hơn. tiêu thụ EOF.

Việc giới thiệu EOF giúp cho nâng cấp tiếp theo trở nên dễ dàng hơn. Phiên bản trưởng thành nhất hiện nay là Mở rộng số học mô- mô-đun EVM (EVM-MAX). EVM-MAX thiết kế một tập hợp các phép toán số học 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 lệnh khác không thể truy cập được. Điều này cho phép hệ thống sử dụng các thuật toán 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 đa dữ liệu lệnh đơn (SIMD). Ý tưởng về SIMD đã có từ lâu trong cộng đồng Ethereum, bắt nguồn từ EIP-616 do Greg Colvin đề xuất. SIMD có thể được sử dụng để tăng tốc các phép tính mật mã khác nhau, bao gồm hàm băm, STARK 32 bit khác nhau và mật mã dựa trên mạng. EVM-MAX kết hợp với hai mở rộng này của SIMD có thể đáp ứng tốt nhu cầu cải thiện hiệu suất của EVM.

Thiết kế sơ bộ của EIP kết hợp này sẽ dựa trên EIP-6690, với mở rộng sau:

• Các loại mô-đun sau được hỗ trợ: (i) bất kỳ số lẻ nào hoặc (ii) 2 lũy lần từ 768 trở xuống.
• Thêm phiên bản mới cho mỗi lệnh EVMMAX (thêm, phụ, mul). Thay vì nhận 3 biến tức thời x, y, z thì phiên bản này nhận 7 biến tức thời: x_start, x_skip, y_start, y_skip, z_start, z_skip, count.

Được biểu thị bằng mã Python, các hướng dẫn này tương đương với:

 for i in range(count): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )

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

• Đối với trường hợp mô đun là lũy thừa của 2, dự kiến ​​sẽ thêm các hướng dẫn vận hành như XOR, AND, OR, NOT và SHIFT (hỗ trợ vòng lặp và không vòng lặp). Ngoài ra, lệnh ISZERO sẽ được thêm vào để đẩy kết quả hoạt động vào ngăn xếp chính EVM.

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

Các giải pháp nâng cấp EVM khác cũng có thể thực hiện được nhưng hiện tại chúng không thu hút được nhiều sự chú ý.

Nó liên quan thế nào đến nghiên cứu hiện tại?

• EOF: https://evmobjectformat.org/
• EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
• SIMD: https://eips.ethereum.org/EIPS/eip-616

Còn lại gì để làm và sự đánh đổi là gì?

Hiện tại có kế hoạch giới thiệu EOF trong đợt hard fork tiếp theo. Mặc dù vẫn có thể loại bỏ tính năng này - các tính năng vào phút cuối đã bị xóa trước khi hard fork- nó sẽ gặp rất nhiều phản kháng. Nếu EOF bị loại bỏ, điều đó có nghĩa là tất cả nâng cấp EVM tiếp theo cần được thực hiện mà không có EOF. Mặc dù điều này khả thi nhưng nó sẽ mang lại nhiều thách thức kỹ thuật hơn.

Sự đánh đổi chính cho EVM là sự cân bằng giữa độ phức tạp L1 và độ phức tạp của cơ sở hạ tầng. EOF sẽ bổ sung một lượng mã đáng kể vào quá trình triển khai EVM và việc kiểm tra mã tĩnh cũng rất phức tạp. Đổi lại, chúng tôi nhận đượ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à lợi nhuận khác. Có thể nói rằng bất kỳ lộ trình nào ưu tiên cải tiến liên tục Ethereum L1 đều nên bao gồm EOF và xây dựng dựa trên nó.

Một trong đó những nhiệm vụ quan trọng là triển khai các chức năng tương tự EVM-MAX kết hợp với SIMD và tiến hành đo điểm chuẩn tiêu thụ gas cho các hoạt động mã hóa khác nhau.

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

Việc điều chỉnh EVM của L1 có thể nhắc L2 thực hiện các thay đổi tương ứng. Trong đó một lớp được điều chỉnh độc lập và lớp kia không thay đổi, nó sẽ gây ra một số vấn đề về khả năng tương thích, điều này sẽ gây ra những tác động tiêu cực khác. Ngoài ra, EVM-MAX kết hợp với chức năng SIMD có thể giảm chi phí gas của các hệ thống kiểm chứng khác nhau, từ đó cải thiện hiệu quả thực thi của lớp L2. Điều này cũng giúp việc loại bỏ nhiều mô-đun được biên dịch trước trở nên dễ dàng hơn vì mô-đun này có thể được thay thế bằng mã EVM mà về cơ bản không ảnh hưởng lớn đế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ỉ hỗ trợ một phương thức xác minh: chữ ký ECDSA. Ban đầu, Trừu tượng hóa tài khoản được thiết kế để vượt qua giới hạn này, cho phép thực hiện logic xác minh tài khoản bằng cách sử dụng mã EVM tùy ý. Điều này sẽ hỗ trợ nhiều tình huống ứng dụng khác nhau:

• Chuyển sang mật mã kháng lượng tử
• Xoay các khóa cũ (đây là một phương pháp bảo mật được chấp nhận rộng rãi)
• Ví đa chữ ký và ví phục hồi xã hội.
• Sử dụng một khóa duy nhất cho các hoạt động có giá trị thấp và một khóa (hoặc nhóm khóa) khác cho các hoạt động có giá trị cao
• Triển khai giao thức bảo mật không lặp lại, giảm đáng kể độ phức tạp của hệ thống và loại bỏ các phụ thuộc cốt lõi

Kể từ khi Trừu tượng hóa tài khoản được đề xuất vào năm 2015, phạm vi mục tiêu của nó đã được mở rộng, bổ sung thêm một số "mục tiêu tiện lợi", chẳng hạn như cho phép tài khoản không có ETH nhưng có token ERC20 cụ thể để thanh toán phí gas trực tiếp bằng cách sử dụng token ERC20 đó . Sơ đồ sau đây tóm tắt các mục tiêu này:

MPC ở đây đề cập đến tính toán nhiều bên : một công nghệ 40 năm lịch sử lưu trữ khóa theo từng phân đoạn trên nhiều thiết bị và sử dụng phương pháp mã hóa để hợp nhất các khóa mà không cần hợp nhất trực tiếp. Chữ ký được tạo ra bằng cách phân mảnh khóa.

EIP-7702 là Đề án dự kiến ​​được giới thiệu trong đợt hard fork tiếp theo. EIP-7702 xuất phát từ sự nhận thức ngày càng tăng rằng cần phải cung cấp chức năng Trừu tượng hóa tài khoản tiện lợi 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 cho mọi người trong thời gian ngắn và tránh hệ sinh thái bị chia thành hai hệ thống độc lập. Công việc này bắt đầu với EIP-3074 và lên đến đỉnh điểm là EIP-7702. EIP-7702 cung cấp ngay "tính năng tiện lợi" của 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).

Như có thể thấy từ biểu đồ, trong khi 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 giao thức tính toán bên long hoặc các công nghệ tiến bộ như EIP-7702, thì hầu hết các mục tiêu bảo mật đã thúc đẩy Đề án Trừu tượng hóa tài khoản ban đầu, chỉ có điều này có thể đạt được bằng cách quay lại và giải quyết vấn đề ban đầu: cho phép mã hợp đồng thông minh trực tiếp kiểm soát quá trình xác minh giao dịch. Tuy nhiên, lý do điều này vẫn chưa đạt được là việc triển khai chức năng này một cách an toàn bản thân nó đã là một thách thức.

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

Về cốt lõi, cốt lõi của 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, không chỉ các tài khoản thuộc sở hữu bên ngoài (EOA), bắt đầu giao dịch. Tất cả sự phức tạp đều xuất phát từ cách thực hiện điều này theo cách giúp duy trì mạng lưới phi tập trung đồng thời bảo vệ khỏi các cuộc tấn công từ chối dịch vụ (DoS).

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

Nếu có 1.000 tài khoản có chức năng xác minh đều phụ thuộc vào giá trị chung S và có nhiều giao dịch hợp lệ trong nhóm bộ nhớ dưới giá trị S hiện tại thì một giao dịch thay đổi giá trị của S có thể khiến tất cả các giao dịch trong nhóm bộ nhớ bị hỏng. thất bại. Các giao dịch khác không hợp lệ. Điều này cho phép kẻ tấn công gửi các giao dịch spam đến mempool với chi phí rất thấp, chiếm tài nguyên của nút mạng.

Trả giá lượng lớn nỗ lực trong nhiều năm để mở rộng chức năng đồng thời hạn chế rủi ro tấn công Từ chối dịch vụ (DoS), cuối cùng cũng có một giải pháp mang lại sự đồng thuận về cách đạt được " Trừu tượng hóa tài khoản lý tưởng": 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ả việc xác nhận đều được xử lý trước tiên, sau đó mới đến việc 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 thực chỉ liên quan đến tài khoản của chính nó và không đọc các biến hoàn cảnh. Điều này ngăn chặn nhiều cuộc tấn công vô hiệu hóa. Đồng thời, giới hạn gas nghiêm ngặt cũng được đặt ra cho bước xác minh.

ERC-4337 ban đầu đượ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 máy trạm Ethereum đang tập trung vào nâng cấp“The Merge” và không có thêm năng lượng để phát triển các tính năng khác. Đây là lý do tại sao ERC-4337 sử dụng một đối tượng tùy chỉnh có tên là Hoạt độ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 ra rằng cần phải kết hợp các phần của nó vào giao thức. Có hai lý do chính:

• EntryPoint vốn có sự thiếu hiệu quả như một hợp đồng: mỗi hoạt động gói yêu cầu thêm khoảng 100.000 gas và mỗi hoạt động của người dùng cần thêm vài nghìn gas.
• Cần phải đảm bảo rằng các tính năng Ethereum, chẳng hạn như đảm bảo bao gồm được cung cấp bởi danh sách bao gồm, hoạt động cho người dùng Trừu tượng hóa tài khoản.

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

• Paymasters : Tính năng này cho phép một tài khoản thanh toán phí thay cho 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 gửi trong giai đoạn xác minh, do đó, các cơ chế xử lý đặc biệt được đưa ra để hỗ trợ cơ chế thanh toán gốc và đảm bảo tính bảo mật của nó.
• Bộ tổng hợp : Tính năng này hỗ trợ 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 mức hiệu quả dữ liệu cao nhất trên Rollups .

Những thông tin nghiên cứu hiện có có sẵn?

• Bài giảng về lịch sử phát triển Trừu tượng hó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 (chức năng tổng hợp): https://github.com/getwax/bls-wallet
• EIP-7562 ( Trừu tượng hóa 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

Những gì khác cần phải được thực hiện, và sự đánh đổi là gì?

Vấn đề chính còn lại là xác định cách kết hợp đầy đủ Trừu tượng hóa tài khoản vào giao thức. Một Đề án gần đây về giao thức ghi Trừu tượng hóa tài khoản đã thu hút nhiều sự chú ý là EIP-7701, thực hiện Trừu tượng hóa tài khoản dựa trên EOF. Tài khoản có thể có phần mã xác minh độc lập. Nếu tài khoản đặt phần mã tương ứng, mã sẽ được thực thi trong bước xác minh các giao dịch do tài khoản thực hiện.

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

1. Kết hợp EIP-4337 vào giao thức
2. Một loại EOA mới có thuật toán chữ ký được thực thi bằng mã EVM

Nếu chúng tôi đặt 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 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í ban đầu đặt giới hạn gas quá thấp để không 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 Phương pháp là Tính bảo mật rất rõ ràng: 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 ràng buộc này vì điều quan trọng là phải 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ư đạt được 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 ra những cách linh hoạt hơn để xử lý rủi ro từ chối dịch vụ (DoS), thay vì yêu cầu các bước xác minh cực kỳ đơn giản.

Sự đánh đổi chính dường như là liệu có nên viết một giải pháp kém thỏa đáng hơn vào thỏa thuận sớm hơn hay đợi lâu hơn và có khả năng đạt được một giải pháp lý tưởng hơn. Phương pháp lý tưởng có thể là một dạng kết hợp nào đó. Một cách tiếp cận kết hợp sẽ là đưa một số trường hợp sử dụng nhất định vào giao thức nhanh hơn, để lại nhiều thời gian hơn để giải quyết các vấn đề khác. Một phương pháp 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 triệt để hơn trên L2. Tuy nhiên, thách thức là để đội ngũ L2 sẵn sàng chấp nhận một Đề án, họ cần phải tin tưởng rằng L1 và các L2 khác sẽ áp dụng giải pháp 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à 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. Để đạt được điều này một cách hiệu quả, L2 có thể cần hỗ trợ các hướng dẫn như L1SLOAD hoặc REMOTESTATICCALL, nhưng điều này cũng yêu cầu việc triển khai Trừu tượng hóa tài khoản trên L2 có thể hỗ trợ nó.

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 bao gồm cần hỗ trợ các giao dịch Trừu tượng hóa tài khoản. Trong thực tế, nhu cầu về danh sách ngăn chặn và mempool phi tập trung cuối cùng rất giống nhau, mặc dù danh sách ngăn chặn có tính linh hoạt hơn. Ngoài ra, lý tưởng nhất là việc triển khai Trừu tượng hóa tài khoản trên L1 và L2 phải nhất quán nhất có thể. Nếu chúng tôi kỳ vọng rằng hầu hết người dùng sẽ sử dụng rollups kho khóa trong tương lai 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 được triển khai 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.

Tuy nhiên, việc triển khai EIP-1559 hiện tại có một số hoàn thiện:

• Công thức này hơi thiếu sót: nó nhằm mục đích lấp đầy khoảng 50-53% số khối (tùy thuộc vào phương sai), chứ không phải 50% (đ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 trung bình số học-hình học")
• Trong trường hợp cực đoan , việc điều chỉnh không đủ nhanh.

Công thức sau này cho dữ liệu(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. Cả EIP-1559 và EIP-4844 đều không cố gắng giải quyết vấn đề thứ hai. Do đó, tình hình hiện tại là một trạng thái chuyển tiếp khó hiểu liên quan đến hai cơ chế khác nhau và thậm chí có lý do cho rằng rằng cả hai cơ chế này sẽ cần được cải thiện theo thời gian.

Ngoài ra, việc định giá tài nguyên của Ethereum còn có một số điểm yếu khác khác với EIP-1559, nhưng những vấn đề này 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 : Giá tài nguyên của Ethereum phải được đặt để xử lý trường hợp xấu nhất (tức là toàn bộ gas tiêu thụ của một khối chiếm một tài nguyên), nhưng mức sử dụng trung bình thì rất xa. Bất cứ điều gì ít hơn thế sẽ dẫn đến sự kém hiệu quả.

Nó 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 mức giá và giới hạn độc lập cho các nguồn tài nguyên khác nhau. Về mặt kỹ thuật, khái niệm này độc lập với EIP-1559, nhưng EIP-1559 giúp dễ triển khai hơn: không có EIP-1559, việc đóng gói các khối một cách tối ưu đối diện đối mặt với nhiều hạn chế về tài nguyên là một vấn đề phức tạp. Với EIP-1559, hầu hết các khối không hoạt động hết công suất trên bất kỳ tài nguyên nào, do đó, thuật toán đơn giản "chấp nhận bất kỳ giao dịch nào trả đủ phí" sẽ đủ.

Hiện tại, chúng tôi có gas đa chiều để thực thi và dữ liệu ; về nguyên tắc, chúng tôi có thể thêm nhiều thứ nguyên hơn: dữ liệu , đọc và ghi trạng thái cũng như mở rộng kích thước trạng thái .

EIP-7706 giới thiệu một thứ nguyên gas mới cho calldata. Đồng thời, nó đơn giản hóa cơ chế gas đa chiều bằng cách làm cho cả ba loại gas tuân theo khuôn khổ (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 chi tiết hơn để xử lý các vấn đề về tài nguyên trong trường hợp trung bình và trường hợp xấu nhất. Nó giới hạn nghiêm ngặt hơn số dữ liệu tối đa mà không giới thiệu một chiều 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 phí cơ sở nhanh hơn trong khi vẫn duy trì tính 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 sẽ xấp xỉ giá trị mục tiêu chính xác hơn).

Những thông tin nghiên cứu hiện có có sẵn?

• 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
• Đề án cải tiến để điều chỉnh nhanh: https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/Transaction_Fees_on_a_Honeymoon_Ethereums_EIP_1559_One_Month_Later.pdf
• Câu hỏi thường gặp về EIP-4844, Phần 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
• Gas đa chiều : https://vitalik.eth.limo/general/2024/05/09/multidim.html

Những gì khác cần phải được thực hiện, và sự đánh đổi là gì?

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

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

Đối với dữ liệu, độ 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 gas nằm bên trong EVM (chẳng hạn như đọc và ghi bộ lưu trữ), vấn đề nghiêm trọng hơn. Vấn đề là không chỉ người dùng đặt giới hạn gas : khi hợp đồng gọi các hợp đồng khác, họ cũng đặt giới hạn. Hiện tại, cách họ đặt ra giới hạn vẫn mang tính một chiều.

Một phương pháp đơ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 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 hoạt động SLOAD tiêu thụ 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% gas thực thi giới hạn) ).

Nghiên cứu thêm về gas đa chiều sẽ rất hữu ích trong việc tìm hiểu 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 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 bớt áp lực tối ưu hóa hiệu suất để hỗ trợ, chẳng hạn như cây băm dựa trên STARK. Đặt mục tiêu rõ ràng để tăng trưởng quy mô tiểu bang có thể giúp các nhà phát triển máy trạm 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, do EOF có đặc điểm không thể quan sát được gas nên nó làm cho các phiên bản Gas đa chiều tiên tiến hơn dễ thực hiện hơ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 các số ngẫu nhiên dựa trên RANDAO để chọn người đề xuất. RANDAO nonces hoạt động bằng cách yêu cầu mỗi người đề xuất tiết lộ những bí mật đã cam kết trước của họ và trộn từng bí mật được tiết lộ thành một số ngẫu nhiên. Do đó, mỗi người đề xuất có "1 chút sức mạnh thao túng": họ có thể thay đổi nonce bằng cách không tạo ra một khối (với trả giá). Điều này có thể chấp nhận được đối với những người đề xuất được chọn vì rất hiếm khi từ bỏ một cơ hội để có được lần cơ hội đề xuất mới. Nhưng đối với các ứng dụng trên Chuỗi yêu cầu số ngẫu nhiên thì điều này là không thể chấp nhận được. Lý tưởng nhất là chúng ta cần tìm một nguồn số ngẫu nhiên mạnh mẽ hơn.

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

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ể được tăng tốc bằng cách song song hóa. Một ví dụ đơn giản là lặp lại phép tính băm: thực hiện for i in range(10**9): x = hash(x). Kết quả đầu ra cùng với bằng chứng SNARK về tính chính xác của nó 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 các đầu ra vẫn chưa được xác định tại thời điểm T: chúng chỉ khả dụng một thời gian sau khi ai đó thực hiện xong tính toán. Vì bất kỳ ai cũng có thể thực hiện phép tính này nên kết quả không thể bị giữ lại và do đó không thể bị thao túng.

Rủi ro chính của chức năng bị trì hoãn có thể kiểm chứng là tối ưu hóa ngẫu nhiên : ai đó tìm ra phương pháp 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. Tối ưu hóa bất ngờ có thể xảy ra theo hai cách:

• Tăng tốc phần cứng : Ai đó đã chế tạo 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ó.
• Song song hóa ngẫu nhiên : Ai đó đã tìm ra phương pháp chạy hàm nhanh hơn bằng cách song song hóa nó, mặc dù làm như vậy tiêu tốn tài nguyên hơn 100 lần.

Nhiệm vụ của việc tạo ra một VDF thành công là tránh được hai vấn đề trên đồng thời đảm bảo nó đủ hiệu quả để có thể thực hiện được (ví dụ: phương pháp dựa trên hàm băm có một vấn đề là việc chứng minh SNARK của hàm băm trong thời gian thực đòi hỏi yêu cầu phần cứng cực cao) . Vấn đề tăng tốc phần cứng thường được giải quyết bằng cách cho phép những người tham gia hàng hóa công tự tạo và phân phối các ASIC dành riêng cho VDF gần như tối ưu.

Những thông tin nghiên cứu hiện có có sẵn?

• Trang web nghiên cứu của VDF: https://vdfresearch.org/
• Suy nghĩ về các cuộc tấn công chống lại VDF được sử dụng trong Ethereum, 2018: https://ethresear.ch/t/verenabled-delay-functions-and-Attacks/2365
• Nghiên cứu về các cuộc tấn công chống lại MinRoot (VDF được đề xuất): https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf

Những gì khác cần phải được thực hiện, và sự đánh đổi là gì?

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ề mọi mặt. Việc tìm kiếm một chức năng như vậy đòi hỏi nhiều công việc hơn. Nếu chúng ta có một chức năng như vậy thì sự cân bằng chính là liệu có đưa nó vào giao thức hay không: đó là sự cân bằng đơn giản giữa chức năng, độ phức tạp của giao thức và rủi ro bảo mật. Nếu chúng ta cho rằng 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, tính bảo mật sẽ bị suy giảm theo giả định RANDAO (1 bit sức mạnh thao túng cho mỗi kẻ tấn công) hoặc tệ hơn một chút. Do đó, ngay cả khi VDF có sai sót, nó sẽ không tự phá vỡ giao thức, mặc dù nó 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 độc lập của giao thức Ethereum và 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 số ngẫu nhiên và có khả năng (ii) nhóm bộ nhớ crypto. Tuy nhiên, việc triển khai nhóm bộ nhớ crypto dựa trên VDF vẫn dựa vào những đột phá về mật mã khác chưa được triển khai.

Điều quan trọng cần lưu ý là, do tính không chắc chắn của phần cứng, có thể có một số "độ trễ" giữa thời điểm đầu ra VDF được tạo ra và thời gian cần thiết. Điều này có nghĩa là thông tin có thể có sẵn trước vài khối. Đây có thể là một cái giá phải trả có thể chấp nhận được, nhưng nó cần được tính đến khi thiết kế các cơ chế như quyết định cuối cùng hoặc lựa chọn ủy ban.

Làm xáo trộn 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 này, ông chỉ ra rằng các ứng dụng bên long 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 bất kỳ người tham gia cụ thể nào.

Cho đến nay chúng ta chỉ mới tiến gần được một phần đế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, trong đó 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ể đạt được điều này, mặc dù mở rộng hạn chế. Nếu quyền riêng tư thực sự là mục tiêu thì cho đến gần đây, chúng tôi chỉ có thể tạo một số giao thức chuyên dụng 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 cho các dạng nặc danh thô, crypto dựa trên danh tính cho phép crypto thuận tiện hơn theo giả định của người dùng, chữ ký mù đối với tiền điện tử Chaumian, v.v. Phương pháp này đòi hỏi lượng lớn 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 ta thấy một phương pháp mới và mạnh mẽ hơn dựa trên mật mã có thể lập trình được. Thay vì phát triển các giao thức chuyên dụng cho từng ứng dụng mới, chúng tôi có thể sử dụng các giao thức mạnh mẽ mới—đặc biệt là ZK-SNARK—để bổ sung các đảm bảo về mật mã cho bất kỳ chương trình nào. 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 này (i) có thể kiểm chứng dễ dàng 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 đột phá cả về quyền riêng tư lẫn mở rộng, và tôi ví nó giống như tác động của Transformer trong lĩnh vực trí tuệ nhân tạo. Hàng ngàn năm nỗ lực của con người dành cho việc phát triển các ứng dụng cụ thể đột nhiên được thay thế bằng một giải pháp phổ quát có thể cắm và chạy để giải quyết lượng lớn vấn đề không mong muốn.

Nhưng ZK-SNARK chỉ là một trong ba giao thức cơ bản đa năng siêu mạnh. 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 Yu-Gi-Oh. Yu-Gi-Oh là trò chơi bài tôi từng chơi và xem trong thời thơ ấu: Thẻ bài 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à truyền thuyết kể rằng sự hiện diện của chúng có thể gây tử vong và chúng mạnh đến mức 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ó ba giao thức thần thánh của Ai Cập:

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

ZK-SNARK là một trong ba giao thức chính đã phát triển khá hoàn thiện. Trong 5 năm qua, ZK-SNARK đã trở thành công nghệ nền tảng của Ethereum về mở rộng và quyền riêng tư, với những cải tiến đáng kể về tốc độ tạo bằng chứng và sự thân thiện với nhà phát triển. Nhưng ZK-SNARK có một hạn chế chính: dữ liệu phải được nắm vững để tạo ra bằng chứng cho nó. Trong các ứng dụng ZK-SNARK, mỗi dữ liệu trạng thái phải có một "chủ sở hữu" duy nhất và mọi hoạt động đọc và ghi đều cần có sự hiện diện và ủy quyền của chủ sở hữu.

Giao thức thứ hai khắc phục hạn chế này và là Crypto hoàn toàn đồng hình ( FHE ). FHE có thể thực hiện các phép tính tùy ý trên dữ liệu crypto mà không cần truy cập dữ liệu gốc . Điều này cho phép chúng tôi xử lý dữ liệu cho người dùng của mình đồng thời bảo vệ quyền riêng tư của dữ liệu và thuật toán. Nó cũng có thể tăng cường các hệ thống bỏ phiếu như MACI, cung cấp sự đảm bảo về quyền riêng tư và bảo mật gần như hoàn hảo. FHE từ lâu đã cho rằng quá kém hiệu quả để có thể áp dụng vào thực tế, nhưng giờ đây hiệu quả của nó đã đạt đến mức thực tế và các ứng dụng liên quan đang bắt đầu xuất hiện.

Nhưng FHE cũng có những hạn chế: bất kỳ công nghệ nào dựa trên FHE vẫn yêu cầu một đối tượng cụ thể giữ khóa giải mã. Mặc dù có thể áp dụng giải pháp phân chia bên long M-of-N và thậm chí sử dụng Hoàn cảnh thực thi tin cậy (TEE) làm lớp bảo vệ thứ hai, nhưng đây vẫn là một hạn chế cố hữu.

Điều này dẫn đến giao thức thứ ba mạnh hơn hai giao thức đầu tiên cộng lại: Che giấu khả năng phân biệt . Mặc dù vẫn còn lâu mới được sử dụng thực tế nhưng vào năm 2020, chúng tôi đã thiết lập một giao thức khả thi 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 nó. 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 crypto" có thể thực hiện các phép tính tùy ý trong khi ẩn hoàn toàn các chi tiết triển khai nội bộ của nó . Một ví dụ đơn giản, bạn có thể bọc private key vào một chương trình bị xáo trộn để nó chỉ có thể được sử dụng để ký các số nguyên tố, sau đó phân phối chương trình cho người khác. Người dùng có thể sử dụng chương trình này để ký bất kỳ số nguyên tố nào nhưng không thể rút private key. Nhưng đây chỉ là phần nổi của tảng băng chìm về khả năng của nó: kết hợp với các hàm băm, nó có thể triển khai bất kỳ nguyên tắc mã hóa nguyên thủy nào khác và hỗ trợ các tính năng nâng cao hơn.

Hạn chế duy nhất của một chương trình bị xáo trộn là nó không thể ngăn chặn việc sao chép chính chương trình đó. Tuy nhiên, một công nghệ mạnh mẽ hơn đã xuất hiện trong lĩnh vực này nhưng nó yêu cầu tất cả người tham gia phải có máy tính lượng tử: Chữ ký lượng tử một lần.

Kết hợp các kỹ thuật che giấu mã nguồn và chữ ký một lần, chúng ta có thể xây dựng một hệ thống bên thứ ba không cần sự tin cậy gần như hoàn hảo. Điều duy nhất dựa vào blockchain và không thể đạt được chỉ bằng mật mã là khả năng chống kiểm duyệt. Những công nghệ này không chỉ có thể nâng cao tính bảo mật của Ethereum mà còn hỗ trợ xây dựng các ứng dụng lớp trên mạnh mẽ hơn.

Để hiểu cách mỗi giao thức cơ bản này cải thiện khả năng của hệ thống, hãy xem một trường hợp điển hình: hệ thống bỏ phiếu . Bỏ phiếu là một bài toán rất khó khăn vì nó cần đáp ứng nhiều đặc tính bảo mật phức tạp, đặc biệt là về khả năng xác minh và quyền riêng tư. Mặc dù các giao thức bỏ phiếu an toàn đã tồn tại trong nhiều thập kỷ, nhưng chúng ta hãy hướng tới mục tiêu cao hơn: thiết kế một hệ thống có thể hỗ trợ các giao thức bỏ phiếu tùy ý, bao gồm bỏ phiếu lần, cấp vốn lần bị ràng buộc theo cặp và cấp vốn lần khớp với cụm, v.v. Nói cách khác, chúng tôi mong đợi liên kết "kiểm phiếu" sẽ hỗ trợ logic chương trình tùy ý.

• Đầu tiên, giả sử chúng tôi ghi lại dữ liệu bỏ phiếu trên Chuỗi . Điều này cho phép xác minh công khai (bất kỳ ai cũng có thể xác minh tính chính xác của kết quả cuối cùng, bao gồm các quy tắc kiểm phiếu và quy tắc tư cách bỏ phiếu) và khả năng chống kiểm duyệt (không thể ngăn người dùng tham gia bỏ phiếu), nhưng thiếu bảo vệ quyền riêng tư.
• Sau đó, chúng tôi giới thiệu công nghệ ZK-SNARKs . Điều này đạt được sự bảo vệ quyền riêng tư : mọi cuộc bỏ phiếu đều nặc danh đồng thời đảm bảo rằng chỉ những người dùng được ủy quyền mới có thể bỏ phiếu và mỗi người dùng chỉ có thể bỏ phiếu một lần.
• Tiếp theo, chúng tôi giới thiệu cơ chế MACI. Nội dung biểu quyết crypto và truyền về máy chủ trung tâm bằng khóa giải mã. Máy chủ trung tâm chịu trách nhiệm thực hiện quy trình kiểm phiếu, bao gồm lọc phiếu bầu trùng lặp và phát hành ZK-SNARK để chứng minh tính chính xác của kết quả. Điều này không chỉ duy trì các đảm bảo nói trên (ngay cả khi máy chủ gian lận!), mà còn cung cấp khả năng bảo vệ chống cưỡng bức trong trường hợp máy chủ trung thực: người dùng không thể chứng minh các lựa chọn bỏ phiếu của mình, ngay cả khi họ chủ động muốn. Điều này là do mặc dù người dùng có thể chứng minh một phiếu bầu lần nhưng họ không thể chứng minh rằng họ không bỏ phiếu khác để bù đắp cho phiếu bầu trước đó. Điều này ngăn chặn hiệu quả việc mua phiếu bầu và các cuộc tấn công khác.
• Chúng tôi thực hiện việc kiểm phiếu trong hoàn cảnh crypto đồng cấu hoàn toàn (FHE) và giải mã thông qua sơ đồ giải mã ngưỡng N/2-of-N. Điều này nâng cấp cơ chế bảo vệ chống cưỡng bức từ độ tin cậy một điểm lên độ tin cậy ngưỡng N/2 .
• Chúng tôi làm xáo trộn mã của chương trình kiểm phiếu và thiết kế chương trình được làm xáo trộn để nó chỉ có thể đưa ra kết quả khi được ủy quyền, có thể là bằng chứng đồng thuận blockchain, Bằng chứng công việc hoặc kết hợp cả hai. Điều này làm cho cơ chế bảo vệ chống cưỡng bức gần như hoàn hảo : trong chế độ đồng thuận blockchain, 51% nút xác minh được yêu cầu thông đồng để bẻ khóa; trong chế độ Bằng chứng công việc , ngay cả khi toàn bộ mạng thông đồng, bằng cách chạy tính toán của người dùng khác nhau. tập hợp con Việc khôi phục hành vi biểu quyết của một người dùng cũng sẽ tốn rất nhiều chi phí. Chúng tôi cũng có thể đưa những nhiễu loạn ngẫu nhiên nhỏ vào kết quả thống kê cuối cùng để cải thiện hơn nữa khả năng che giấu hành vi bỏ phiếu của từng người dùng.
• Chúng tôi giới thiệu cơ chế chữ ký một lần, một giao thức cơ bản dựa trên điện toán lượng tử nhằm đảm bảo rằng chữ ký chỉ có thể được sử dụng để ký các loại tin nhắn cụ thể một lần. Điều này đạt được sự bảo vệ hoàn toàn chống lại căng thẳng .

Tính năng che giấu không thể phân biệt được cũng có thể hỗ trợ các kịch bản ứng dụng mạnh mẽ khác. Ví dụ:

• Hỗ trợ DAO, đấu giá trên Chuỗi và các ứng dụng khác với bất kỳ trạng thái crypto nội bộ nào .
• Thiết lập đáng tin cậy hoàn toàn chung : Nhà phát triển có thể tạo một chương trình bị xáo trộn có chứa một khóa có thể thực thi một chương trình tùy ý và đưa ra kết quả, lấy hàm băm ( Key, chương trình) làm tham số đầu vào. Sau khi bất kỳ ai có được chương trình này, họ có thể nhúng chương trình vào chính mình, hợp nhất khóa gốc của chương trình với khóa riêng của họ, từ đó mở rộng phạm vi khởi tạo. Điều này có thể được sử dụng để tạo ra 1/N khởi tạo đáng tin cậy cho các giao thức tùy ý.
• ZK-SNARK chỉ yêu cầu xác minh chữ ký . Việc triển khai rất đơn giản: Khởi tạo đáng tin cậy tạo ra một chương trình bị xáo trộn, chỉ ký bằng khóa khi xác minh rằng ZK-SNARK hợp lệ. .
• Nhóm giao dịch crypto . Nó đơn giản hóa đáng kể quá trình crypto giao dịch: giao dịch chỉ được giải mã khi các sự kiện cụ thể 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 thành công VDF (Chức năng trì hoãn có thể xác minh).

Với cơ chế 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% phá hủy tính hữu hạn nhưng vẫn có thể phải đối mặt với các cuộc tấn công kiểm duyệt. Các giao thức cơ bản như chữ ký một lần có thể hỗ trợ tiền lượng tử và giải quyết vấn đề chi tiêu gấp đôi mà không cần dựa vào blockchain, nhưng các kịch bản ứng dụng phức tạp hơn vẫn yêu cầu hỗ trợ blockchain. Nếu các giao thức cơ bản này có thể đạt được mức hiệu suất đủ thì hầu hết các ứng dụng trên thế giới sẽ có khả năng phi tập trung. Nút thắt chính là làm thế nào để xác minh tính đúng đắn của việc thực hiện.

Những thông tin nghiên cứu hiện có có sẵn?

• Nghiên cứu về giao thức che giấu không thể phân biệt được năm 2021: https://eprint.iacr.org/2021/1334.pdf
• Việc che giấu có thể giúp ích cho Ethereum như thế nào: https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380
• Sơ đồ xây dựng chữ ký một lần đầu tiên: https://eprint.iacr.org/2020/107.pdf
• Khám phá triển khai công nghệ che giấu (1): https://mediatum.ub.tum.de/doc/1246288/1246288.pdf
• Khám phá triển khai công nghệ che giấu (2): https://github.com/SoraSuegami/iOMaker/tree/main

Những gì khác cần phải được thực hiện, và sự đánh đổi là gì?

Vẫn còn nhiều thách thức kỹ thuật phía trước . Công nghệ che giấu không thể phân biệt được vẫn còn rất non nớt và các giải pháp xây dựng hiện tại chạy chậm hơn hàng triệu lần (hoặc thậm chí nhiều hơn) và không thể sử dụng trong các ứng dụng thực tế. Công nghệ này được biết đến rộng rãi nhờ thời gian chạy đa thức "về mặt lý thuyết", nhưng trên thực tế, nó mất nhiều thời gian hơn cả thời gian tồn tại của vũ trụ. Theo ước tính của một nhà phát triển, mặc dù các giao thức gần đây đã giảm thiểu tối đa chi phí thời gian nhưng mức phạt về hiệu suất vẫn quá cao đối với các ứng dụng hàng ngày: một lần thực thi lần dự kiến ​​sẽ mất một năm.

Các máy tính lượng tử hiện tại vẫn chưa được hiện thực hóa: tất cả các ý tưởng được thấy trực tuyến cho đến nay đều là hệ thống nguyên mẫu chỉ có thể xử lý các hoạt động 4 bit hoặc chúng 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 thành phần lượng tử nhưng chúng không thể thực hiện các hoạt động thực tế. và các thuật toán lượng tử hiệu quả, chẳng hạn như thuật toán Shor hoặc thuật toán 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, ngày mà người bình thường có quyền truy cập vào 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 lớn 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.

Sự đánh đổi cốt lõi trong các kỹ thuật che giấu không thể phân biệt được là giả định về bảo mật. Mặc dù một số giải pháp căn bản sử dụng các giả định độc đáo có hiệu quả thực thi thực tế hơn nhưng những giả định độc đáo này thường có rủi ro bị vi phạm. Khi hiểu biết lý thuyết của chúng ta về mật mã mạng được cải thiện, cuối cùng chúng ta có thể thiết lập được các giả thuyết không thể phá vỡ. Nhưng con đường này rủi ro. Con đường tương đối thận trọng là tuân theo các giao thức có thể được giảm bớt một cách có thể chứng minh được thành "các giả định tiêu chuẩn", nhưng điều này có nghĩa là sẽ mất nhiều thời gian hơn để đạt được một giao thức có đủ hiệu quả thực thi.

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ã mạnh mẽ có thể là yếu tố thay đổi cuộc chơi. Ví dụ:

• Nếu việc xác minh ZK-SNARK đơn giản như chữ ký, chúng tôi có thể không cần bất kỳ giao thức tổng hợp nào nữa và hoàn tất xác minh trực tiếp trên Chuỗi.
• Chữ ký một lần có thể có nghĩa là các 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 EVM "chỉ" hỗ trợ bảo vệ quyền riêng tư.
• Việc triển khai mempool giao dịch crypto trở nên dễ dàng hơn.

Ban đầu, những lợi ích đổi mới này sẽ được cảm nhận ở lớp ứng dụng, vì Ethereum L1 vốn dĩ cần phải thận trọng trong các giả định về bảo mật của nó. Tuy nhiên, chỉ áp dụng ở lớp ứng dụng cũng có thể dẫn đến những đột phá mang tính cách mạng, có thể so sánh với sự ra đời của ZK-SNARK.

Tuyên bố miễn trừ trách nhiệm: Là một nền tảng thông tin blockchain, các bài viết được xuất bản trên trang này chỉ thể hiện quan điểm tác giả và khách và không liên quan gì đến quan điểm của Web3Caff. Thông tin trong bài viết chỉ tham khảo và không cấu thành bất kỳ lời khuyên hay đề nghị đầu tư nào. Vui lòng tuân thủ luật pháp và quy định có liên quan của quốc gia hoặc khu vực nơi bạn sinh sống.