Vitalik về tương lai có thể có của Ethereum (6): Sự phô trương
Được tổng hợp bởi trí tuệ nhân tạo
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 để dễ đọc và dễ hiểu):
Một số điều rất khó để phân loại thành một loại duy nhất, có rất nhiều "chi tiết" 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 "phát triển mạnh".
Lộ trình 2023: Thịnh vượng
Sự thịnh vượng: Mục tiêu chính
Biến EVM thành một "trạng thái cuối" ổn định và hiệu suất cao p>
Đư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, cải thiện khả năng mở rộng trong khi giảm rủi ro
Khám phá Mật mã nâng cao, làm cho Ethereum tốt hơn đáng kể về lâu dài
Trong chương này
VDF (Chức năng trì hoãn có thể xác minh)
Việc che giấu mã nguồ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
Những 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 từ EVM) và dữ liệu (có thể đọc nhưng không thể thực thi)
·Cấm nhảy động, 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
·Một cơ chế chương trình con rõ ràng mới đã được thêm vào
Cấu trúc của mã EOF
Bùng nổ: Cải tiến EVM (tiếp theo)
Các hợp đồng cũ sẽ tiếp tục tồn tại và có thể được tạo ra, mặc dù cuối cùng chúng có thể bị loại bỏ (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ừ mức tăng 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 của 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. Bả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 một tập hợp các phép toán mới dành riêng cho số học modulo 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, giúp sử dụng các phép toán như Phép nhân Montgomery và các tối ưu hóa khác đều có thể thực hiện được.
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 của Ethereum từ lâu, lần đầu tiên được đề xuất bởi <. a href="https://eips.ethereum.org/EIPS/eip-616" target="">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ộ cho 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 làm mô đun
·Đối với mỗi EVM -MAX opcodes (cộng, trừ, nhân), thêm phiên bản không còn sử dụng 3 số liền nhau x, y, z mà dùng 7 số liền nhau: 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:
·for i in range(count):
mem[z_start + z_skip * count] = op(
mem [x_start + x_skip * count],
mem[y_start + y_skip * count]
)
Trong thực tế triển khai, đ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ư SHA256, KECCAK, BLAKE) và dựa trên về mật mã Lattice. Có thể nâng cấp EVM khác nhưng cho đến nay ít được chú ý hơn.
Các liên kết 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 plan Bao gồm trong đợ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ơ sở hạ tầng, EOF là số lượng lớn mã cần được thêm vào quá trình triển khai EVM và tĩnh việc kiểm tra mã 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ể cho rằng, lộ trình ưu tiên cải tiến liên tục cho 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 như 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ó để giúp L2 dễ dàng điều chỉnh cho phù hợp hơn. Nếu cả hai không được điều chỉnh đồng bộ, có thể gây ra sự không tương thích và mang lại 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ả.
Tắt 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 nhiều ứng dụng:
· Chuyển sang mật mã kháng lượng tử
· Xoay vòng các khóa cũ (rộng rãi Được coi là biện pháp bảo mật được đề xuất)
·Ví đa chữ ký và Ví khôi phục 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 p>
Cho phép các giao thức bảo mật hoạt động mà không cần chuyển tiếp, giảm đáng kể độ phức tạp của chúng và loại bỏ điểm phụ thuộc trung tâm quan trọng
Kể từ năm 2015 Kể từ khi tính năng trừu tượng hóa tài khoản được đề xuất vào năm 2017, nó các mục tiêu cũng đã được 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 có một số ERC20 có thể thanh toán gas bằng ERC20. Dưới đây là biểu đồ tóm tắt về những mục tiêu này:
MPC (Tính toán nhiều bên) là một phương pháp hiện cóCông nghệ 40 năm tuổi để chia khóa thành nhiều phần và lưu trữ chúng trên nhiều thiết bị, tận dụng các 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 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 để 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 trải nghiệm cho tất cả người dùng trong thời gian ngắn, và tránh chia thành hai hệ sinh thái.
Công việc này bắt đầu với EIP-3074 và cuối cùng hình thành EIP-7702. EIP-7702 mang đến "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, tức là các tài khoản được kiểm soát bởi chữ ký ECDSA).
Như bạn có thể thấy từ 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ệ tiên tiến như tính toán nhiều bên hoặc EIP-7702, tài khoản sự trừu tượng hóa ban đầu được đề xuất Mục tiêu bảo mật chính của đề xuất chỉ 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 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à 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 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 đề xảy ra nhiều thất bại:
Nếu có 1000 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 các giao dịch trong mempool trở nên hợp lệ, sau đó một giao dịch đơn lẻ lật giá trị của S có thể làm mất hiệu lực tất cả các giao dịch khác trong mempool. Đ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), cuối cùng chúng tôi đã tìm ra giải pháp để đạt được "sự trừu tượng hóa tài khoản lý tưởng": ERC-4337.
Công việc của ERC- 4337 Nguyên tắc là 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, một hành động 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 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à bạn không cần phải sử dụng thêm năng lượng để xử lý các chức năng khác. Đây 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.
Có hai lý do chính như sau:
1. EntryPoint vốn có những điểm kém hiệu quả như một hợp đồng: chi phí cố định khoảng 100.000 gas mỗi gói và thêm hàng nghìn gas cho mỗi hoạt động của người dùng.
2. Sự cần thiết của việc đả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 tài khoản người dùng trừu tượng.
Ngoài ra, ERC-4337 còn mở rộng thêm 2 chức năng:
·Paymasters: Chức năng cho phép một tài khoản thanh toán phí thay mặt 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 người gửi trong giai đoạn xác minh, do đó, quy trình xử lý đặc biệt được áp dụng để đảm bảo tính bảo mật của khoản thanh toán. cơ chế đại lý.
·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 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 (sử dụng 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
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 ghi 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 đó.
Loại này Đ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. 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 ta có thể Bắt đầu từ việc thiết lập các giới hạn nghiêm ngặt trên độ phức tạp của mã thực thi - không được phép truy cập vào trạng thái bên ngoài và thậm chí giới hạn khí được đặt ban đầu 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ì tính bảo mật của phương pháp này trở nên rõ ràng: Chỉ cần thay thế xác minh ECDSA bằng Thực thi mã EVM mất thời gian tương tự.
Tuy nhiên, theo thời gian, chúng ta sẽ cần phải nới lỏng những giới hạn này vì các ứng dụng bảo vệ quyền riêng tư được phép hoạt động mà không cần chuyển tiếp, cũng như khả năng kháng lượng tử là rất 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à "nhanh chóng viết một giải pháp 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", lý tưởng cách tiếp cận có thể là một số loại phương pháp tiếp cận lai. 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 để 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à 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. Để thực hiện việc này một cách hiệu quả có thể yêu cầu hỗ trợ L2 như L1SLOAD hoặc REMOTESTATICCALL opcode, nhưng điều này cũng yêu cầu triển khai tính năng trừu tượng hóa tài khoản trên L2 để hỗ trợ 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?
Danh sách bao gồm cần hỗ trợ các giao dịch trừu tượng tài khoản. Trong thực tế, các yêu cầu của danh sách bao gồm thực sự rất giống với yêu cầu của nhóm bộ nhớ phi tập trung, mặc dù đối với danh sách bao gồm Nó linh hoạt hơn một chút. 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 dự kiến hầu hết người dùng sẽ 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.
Những cải tiến của 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ờ
Tuy nhiên, hiện tại Việc triển khai EIP-1559 không hoàn hảo về một số mặt:
1. Công thức có một chút sai 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 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").
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 trường hợp trung bình và trường hợp xấu nhất: giá tài nguyên trong Ethereum phải được đặt để xử lý trường hợp xấu nhất, trong đó toàn bộ mức tiêu thụ gas của một khối sẽ chiếm một tài nguyên, nhưng mức sử dụng trung bình thực tế lại cao hơn nhiều. thấp hơn mức này dẫn đến kém hiệu quả.
Là gì Khí đa chiều, nó hoạt động như thế nào?
Giải pháp cho những sự thiếu hiệu quả này là Khí đa chiều: Đặt mức giá và giới hạn khác nhau cho các 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 dễ dàng hơn. Nếu không có EIP-1559, việc đóng gói một khối với nhiều hạn chế về tài nguyên một cách tối ưu sẽ là một vấn đề về 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 ta đã có Gas đa chiều để thực thi và các khối dữ liệu; về nguyên tắc, chúng ta có thể mở rộng nó 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 thứ nguyên khí mới dành riêng cho calldata. Đồng thời, nó cũng đơn giản hóa cơ chế khí đa chiều bằng cách thống 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à giải pháp chính xác hơn cho các tình huống trung bình và trường hợp xấu nhất giới hạn dữ liệu cuộc gọi tối đa mà không giới thiệu một chiều hoàn toàn mới.
Một hướng nghiên cứu tiếp theo là giải quyết vấn đề về tốc độ cập nhật và tìm ra thuật toán tính toán chi phí cơ bản nhanh hơn trong khi vẫn giữ được những điểm khác biệt chính do biến EIP-4844 đưa ra. (tức là về lâu dài, mức sử dụng trung bình gần đúng với giá trị mục tiêu).
Các liên kết 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 về EIP-1559: Phân tích thực nghiệm
Đề xuất cải tiến cho phép điều chỉnh nhanh chóng: Các cải tiến được đề xuất
EIP-4844 Câu hỏi thường gặp về cơ chế tính phí cơ bản: 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
còn lại Những nỗ lực và sự đánh đổi là gì?
Có hai sự đánh đổi chính của Gas đa chiều:
1. Độ phức tạp của giao thức tăng lên: giới thiệu Gas đa chiều Điều này sẽ làm cho thỏa thuận 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 khối: Thuật toán tối ưu cần thiết để lấp đầy khối theo dung lượng cũng sẽ trở nên phức tạp.
Độ phức tạp của giao thức tương đối nhỏ đối với dữ liệu cuộc gọi, nhưng đối với các kích thước khí bên trong EVM (chẳng hạn như đọc và ghi lưu trữ), giới tính phức tạp sẽ tăng lên. 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à 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 sẽ bị tính 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 phải EOF cũng sẽ bị tính phí 0,03% giới hạn gas thực thi).
Nghiên cứu thêm về Khí đa chiều sẽ giúp hiểu được 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 áp lực tối ưu hóa hiệu suất nhằm 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ó.
Hàm độ trễ có thể xác minh (VDF)
Nó giải quyết 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. Tính ngẫu nhiên của RANDAO đạt được bằng cách yêu cầu mỗi người đề xuất tiết lộ bí mật mà họ đã cam kết trước và chỉ định mỗi bí mật được tiết lộ hỗn hợp. vào sự ngẫu nhiên để làm việc.
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 bị trì hoãn có thể kiểm chứng là một hàm chỉ có thể được đánh giá một cách tuần tự và không thể được tăng tốc bằng cách song song hóa. Một ví dụ đơn giản là việc băm lặp lại: for i in range(10**9): x = hash(x). Đầu ra, đã được chứng minh là đúng khi sử dụ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 chưa được biết tại thời điểm T: đầu ra chưa được biết cho đến khi ai đó chạy xong tính toán Sẽ có sẵn vào một thời điểm nào đó sau T. 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 với hàm bị trì hoãn có thể kiểm chứng là việc tối ưu hóa ngoài ý muốn: ai đó thấy mình chạy hàm nhanh hơn dự kiến, từ đó thao túng thông tin họ tiết lộ tại thời điểm T .
Việc tối ưu hóa không mong đợi 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 đề này trong khi vẫn duy trì hiệu quả và thiết thực (ví dụ: đối với các phương pháp tiếp cận dựa trên hàm băm, một vấn đề là thực hiện các hàm băm trong bằng chứng SNARK thời gian thực yêu cầu 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.
Các liên kết nghiên cứu hiện có
Trang web nghiên cứu của VDF: vdfresearch.org
Suy nghĩ về các cuộc tấn công VDF trong Ethereum, 2018: Suy nghĩ về các cuộc tấn công
Các cuộc tấn công vào VDF MinRoot được đề xuất: Các cuộc tấn công chống lại MinRoot
Công việc còn lại và sự đánh đổi Nó 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. 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 ta coi VDF là an toàn nhưng hóa ra nó 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 theo giả định RANDAO (mỗi kẻ tấn công 1 điều khiển) 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 tính bảo mật cho việc lựa chọn người đề xuất, còn hữu ích cho (i) các ứng dụng trên chuỗi dựa vào tính ngẫu nhiên và ( ii) ) cũng có các ứng dụng trong nhóm bộ nhớ được mã hóa, mặc dù việc tạo nhóm bộ nhớ được mã hóa dựa trên VDF vẫn dựa vào các khám phá mậ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, sẽ có một số "chênh lệch" giữa việc tạo ra đầu ra VDF và nhu cầu. Điều này có nghĩa là thông tin sẽ có sẵn cách đây vài khối. Đây có thể là một chi phí có thể chấp nhận được nhưng cần được 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 tôi lý tưởng chỉ có thể được thực hiện một phần. 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 mục tiêu là quyền riêng tư 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, mã hóa dựa trên danh tính để mã hóa thuận tiện hơn với các giả định cụ thể về tổ chức 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 tôi lần đầu tiên có được cái nhìn đầu tiên 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 một 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 cứ điều gì khác ngoài chính xác nhận quyền sở hữu bất kỳ dữ liệu nào khác ngoài . Đâ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 loại nguyên thủy có mục đích chung cực kỳ mạnh mẽ tương tự. Những giao thức này mạnh mẽ đến mức khi tôi nghĩ 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 tử vong và sức mạnh của chúng khiến việc sử dụng chúng trong các trận đấu tay đôi bị cấm. . Tương tự, trong mật mã, chúng ta cũng 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 công việc Đang làm việc?
ZK-SNARK là một trong ba giao thức mà chúng tôi đã có và 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ó hạn chế này là mã hóa đồng hình hoàn toàn (FHE) cho phép bạn thực hiện mã hóa trên dữ liệu được mã hóa mà không cần xem bất kỳ phép tính nào. . Đ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.
Chữ thảo là một chương trình ứng dụng thúc đẩy 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 bảo vệ 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 yêu cầu ai đó 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 đó vẫn là một hạn chế.
Tiếp theo là giao thức thứ ba, 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ệ này 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.
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ả 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à các chương trình che giấu không thể phân biệt được không thể làm là ngăn chặn việc bị sao chép. 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 tính năng che giấu mã nguồn và một lần Với dấu hiệu tình dục, 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. Mục tiêu duy nhất không thể đạt được chỉ bằng mật mã và vẫn cần có 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 có đặc tính bảo mật mạnh đã tồn tại trong nhiều thập kỷ, nhưng chúng ta có thể gây khó khăn hơn 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. 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ư.
Sau đó, chúng tôi đã thêm ZK-SNARK và bây giờ 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, mỗi cử tri A 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 thành khóa giải mã cho máy chủ trung tâm. Máy chủ trung tâm chịu trách nhiệm tiến hành quá trình kiểm phiếu, bao gồm loại bỏ phiế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 tiến hành kiểm phiếu trong FHE, sau đó là tính toán 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ể dựa trên bằng chứng đồng thuận trên blockchain. một số loại bằng chứng công việc, hoặc sự kết hợp của cả hai. Điều này làm cho đảm bảo chống cưỡng bứ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 khối lượ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 con khác nhau; của cử tri để thử Hành động khai thác cá nhân cử tri cũng sẽ vô cùng 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 phương pháp cơ bản dựa trên điện toán lượng tử để cho phép chữ ký chỉ được sử dụng một lần 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.
Tính năng che giấu không thể phân biệt 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 đáng tin cậy phổ quát thực sự: 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 sẽ băm(key ,program) như nhập vào chương trình. Với một chương trình như vậy, bất kỳ ai cũng có thể đư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 cài đặt đáng tin cậy 1/N cho bất kỳ giao thức nào.
3. Việc xác minh ZK-SNARK chỉ cần một chữ ký: đạt được điều này rất đơn giản: thiết lập một môi trường đáng tin cậy, cho phép ai đó tạo một chương trình bị xáo trộn và chỉ Khóa sẽ chỉ được sử dụng để ký tin nhắn 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ực tuyến 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 được thực hiện thành công (VDF).
Với chữ ký một lần, chúng tôi có thể làm cho chuỗi khối miễn nhiễm với các cuộc tấn công 51% vào 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 thứ nguyên thủy này có thể trở nê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 . Việc che giấu có thể giúp ích cho Ethereum: Việc che giấu 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: Việc xây dựng chữ ký một lần đầu tiên được biết đến
4. Nỗ lực làm xáo trộn (1): Đã cố gắng thực hiện Che giấu (1)
5. Cố gắng thực hiện che giấu (2): Đã cố gắng thực hiện kỹ thuật che giấu (2)
Những gì còn lại 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ông trình ứ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) so với Không có sẵn trong ứ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á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 đơn giản là không Các máy tính lượng tử đáng kể, mặc dù chúng có thể có các bộ phận lượng tử, nhưng không thể chạy các phép tính có ý nghĩa 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, 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ự đánh đổi quan trọng là giả định về bảo mật và có những thiết kế mạnh mẽ 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 các 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 có quá trình xác minh đơn giản như việc 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;
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, các lợi ích sẽ xảy ra ở lớp ứng dụng, vì L1 của Ethereum vốn dĩ 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.
「 Liên kết gốc"
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
