Hướng phát triển tương lai của giao thức Ethereum: Chương thịnh vượng
Trong thiết kế giao thức Ethereum có nhiều "chi tiết" quan trọng quyết định sự thành công của nó. Khoảng một nửa nội dung liên quan đến các loại cải tiến EVM khác nhau, phần còn lại bao gồm nhiều chủ đề ngách khác nhau, đó chính là ý nghĩa của "thịnh vượng".
Thịnh vượng: Mục tiêu chính
Biến EVM thành "trạng thái cuối cùng" hiệu suất cao và ổn định
Đưa 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 tài khoản an toàn và tiện lợi hơn
Tối ưu hóa chi phí giao dịch, nâng cao khả năng mở rộng đồng thời giảm rủi ro
Khám phá mật mã tiên tiến, giúp Ethereum cải thiện đáng kể trong dài hạn
Cải tiến EVM
Đã giải quyết vấn đề gì?
Hiện tại, EVM khó khăn trong việc phân tích tĩnh, điều này làm cho việc tạo ra các triển khai hiệu quả, xác minh chính thức mã và thực hiện mở rộng thêm trở nên khó khăn. Ngoài ra, hiệu suất của EVM thấp, khó khăn trong việc thực hiện nhiều hình thức mật mã cao cấp, trừ khi được hỗ trợ rõ ràng thông qua việc biên dịch trước.
Nó là gì, 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 trong đợt phân tách cứng tiếp theo. EOF là một loạt EIP, xác định một phiên bản mã EVM mới với nhiều đặc điểm độc đáo, nổi bật nhất là:
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 giữa ).
Cấm chuyển tiếp động, chỉ cho phép chuyển tiếp tĩnh
Mã EVM không thể quan sát thông tin liên quan đến nhiên liệu nữa.
Đã thêm một cơ chế ví dụ rõ ràng mới
Cấu trúc mã EOF bao gồm đoạn mã, đoạn dữ liệu và đoạn thông tin kiểu.
Khi giới thiệu EOF, việc nâng cấp thêm trở nên dễ dàng hơn, hiện tại sự phát triển hoàn thiện nhất là mở rộng số học mô-đun EVM ( EVM-MAX ). EVM-MAX tạo ra một tập hợp các lệnh mới chuyên biệt cho phép tính toán mô-đun và đặt chúng vào một không gian bộ nhớ mới không thể truy cập bởi các mã lệnh khác, điều này cho phép sử dụng các 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 tính SIMD (Single Instruction Multiple Data) (. SIMD có thể được sử dụng để tăng tốc nhiều hình thức mật mã, bao gồm hàm băm, STARKs 32 bit và mật mã dựa trên lưới, sự kết hợp giữa EVM-MAX và SIMD khiến cho hai loại mở rộng hướng đến hiệu suất này trở thành một cặp tự nhiên.
) Liên kết nghiên cứu hiện có
EOF:
EVM-MAX:
SIMD:
Công việc còn lại và sự cân nhắc
Hiện tại, EOF dự kiến sẽ được đưa vào trong hard fork tiếp theo. Mặc dù luôn có khả năng loại bỏ nó vào phút chót, nhưng việc làm như vậy sẽ gặp nhiều thách thức lớn. Việc loại bỏ EOF có nghĩa là bất kỳ bản nâng cấp nào của EVM trong tương lai sẽ cần được thực hiện mà không có EOF, mặc dù có thể làm được, nhưng có thể sẽ khó khăn hơn.
Sự đánh đổi chính của EVM nằm ở độ phức tạp của L1 và độ phức tạp của cơ sở hạ tầng, EOF là một lượng lớn mã cần được thêm vào việc triển khai EVM, kiểm tra mã tĩnh cũng tương đối 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à nhiều lợi ích khác. Có thể nói, lộ trình ưu tiên cải tiến liên tục Ethereum L1 nên bao gồm và xây dựng dựa trên EOF.
Công việc quan trọng cần thực hiện là triển khai chức năng tương tự như EVM-MAX cộng với SIMD, và tiến hành kiểm tra hiệu suất tiêu thụ gas của các hoạt động mã hóa khác nhau.
Làm thế 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 mình để L2 cũng có thể dễ dàng thực hiện điều chỉnh tương ứng, nếu hai bên không thực hiện điều chỉnh đồng bộ, có thể gây ra sự không tương thích, mang lại ảnh hưởng tiêu cực. Ngoài ra, EVM-MAX và SIMD có thể giảm chi phí gas của nhiều hệ thống chứng minh, từ đó làm cho L2 hiệu quả hơn. Nó cũng giúp việc thay thế nhiều mã biên dịch trước bằng mã EVM có thể thực hiện cùng một nhiệm vụ trở nên dễ dàng hơn, có thể không ảnh hưởng đáng kể đến hiệu suất.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Trừu tượng tài khoản
) Giải quyết vấn đề gì?
Hiện tại, giao dịch chỉ có thể được xác thực bằng một cách: chữ ký ECDSA. Ban đầu, trừu tượng hóa tài khoản nhằm vượt qua điều này, cho phép logic xác thực của tài khoản là mã EVM tùy ý. Điều này có thể kích hoạt một loạt các ứng dụng:
Chuyển sang mật mã kháng lượng tử
Luân chuyển khóa cũ ### được coi là thực hành an toàn được khuyến nghị (
Ví đa chữ ký và ví phục hồi xã hội
Sử dụng một khóa để thực hiện các hoạt động có giá trị thấp, sử dụng một khóa khác ) hoặc một bộ khóa ( để thực hiện các hoạt động có giá trị cao.
Cho phép giao thức bảo mật hoạt động mà không cần trung gian, giảm đáng kể độ phức tạp của nó và loại bỏ một điểm phụ thuộc trung ương quan trọng.
Kể từ khi khái niệm trừu tượng tài khoản được đưa ra vào năm 2015, mục tiêu của nó cũng đã mở rộng để bao gồm nhiều "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 sở hữu một số ERC20 có thể sử dụng ERC20 để thanh toán gas.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Nó là gì, hoạt động như thế nào?
Cốt lõi của trừu tượng tài khoản là đơn giản: cho phép hợp đồng thông minh khởi xướng giao dịch, chứ không chỉ là EOA. Tất cả sự phức tạp đến từ việc thực hiện điều này theo cách thân thiện với việc duy trì mạng phi tập trung và ngăn chặn các cuộc tấn công từ chối dịch vụ.
Một thách thức chính điển hình là vấn đề sai lệch đa dạng: nếu có 1000 tài khoản có hàm xác minh đều phụ thuộc vào một giá trị duy nhất S, và giá trị S hiện tại khiến cho các giao dịch trong bộ nhớ hồ bơi đều hợp lệ, thì một giao dịch đơn lẻ lật ngược giá trị S có thể khiến tất cả các giao dịch khác trong bộ nhớ hồ bơi trở nên không hợp lệ. Điều này cho phép kẻ tấn công gửi các giao dịch rác đến bộ nhớ hồ bơi với chi phí rất thấp, từ đó làm tắc nghẽn tài nguyên của các nút mạng.
Sau nhiều năm nỗ lực, 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 đã đưa ra giải pháp để hiện thực hóa "trừu tượng tài khoản lý tưởng": ERC-4337.
Cách hoạt động của ERC-4337 là chia quá trình xử lý các 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 minh được xử lý trước, tất cả các thực thi sau đó được xử lý. Trong bộ nhớ, chỉ khi 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 họ và không đọc biến môi trường, thì mới được chấp nhận. Điều này có thể ngăn chặn các cuộc tấn công từ việc không thành công nhiều lần. Ngoài ra, cũng áp dụng các hạn chế gas nghiêm ngặt cho bước xác minh.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Liên kết nghiên cứu hiện có
Bài phát biểu về lịch sử trừu tượng tài khoản:
ERC-4337:
EIP-7702:
Mã BLSWallet ### sử dụng chức năng tổng hợp (:
EIP-7562) viết vào giao thức trừu tượng tài khoản (:
EIP-7701) giao thức viết dựa trên EOF tài khoản trừu tượng (:
) Công việc còn lại và sự cân nhắc
Hiện tại, vấn đề chính cần giải quyết là làm thế nào để hoàn toàn tích hợp trừu tượng hóa tài khoản vào giao thức. Gần đây, EIP trừu tượng hóa tài khoản được ưa chuộng là EIP-7701, đề xuất này thực hiện trừu tượng hóa tài khoản trên EOF. Một tài khoản có thể có một phần mã riêng biệt để xác thực, nếu tài khoản đó đã thiết lập phần mã này, thì phần mã đó sẽ được thực thi trong bước xác thực của giao dịch từ tài khoản đó.
Điều hấp dẫn của phương pháp này là nó rõ ràng chỉ ra hai quan điểm tương đương của trừu tượng tài khoản địa phương:
Đưa EIP-4337 vào như một phần của giao thức
Một loại EOA mới, trong đó thuật toán chữ ký là thực thi mã EVM
Nếu chúng ta bắt đầu từ việc đặt ra giới hạn nghiêm ngặt về độ phức tạp của mã có thể thực thi trong thời gian xác thực, thì tính an toàn của phương pháp này trở nên rất rõ ràng: chỉ cần thay thế xác thực ECDSA bằng việc thực thi mã EVM cần thời gian tương tự.
Tuy nhiên, theo thời gian, chúng ta cần nới lỏng những giới hạn này, vì việc cho phép các ứng dụng bảo vệ quyền riêng tư hoạt động mà không cần trung gian, cũng như khả năng kháng lại lượng tử là rất quan trọng. Để làm được điều này, chúng ta cần tìm ra những phương pháp 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 phải cực kỳ đơn giản.
Sự cân nhắc chính dường như là "viết nhanh một giải pháp mà ít người hài lòng" với "chờ đợi lâu hơn, có thể đạt được giải pháp lý tưởng hơn", phương pháp lý tưởng có thể là một phương pháp kết hợp. Một phương pháp kết hợp là viết nhanh một số trường hợp sử dụng và dành nhiều thời gian hơn để khám phá các trường hợp sử dụng khác. Một phương pháp khác là triển khai phiên bản trừu tượng tài khoản tham vọng hơn trên L2 trước tiên. Tuy nhiên, thách thức mà điều này đối mặt là đội ngũ L2 cần phải có niềm tin vào công việc của đề xuất để sẵn sàng thực hiện, đặc biệt là để đảm bảo rằng L1 và/hoặc các L2 khác trong tương lai có thể áp dụng các giải pháp tương thích.
Một ứng dụng khác mà chúng ta cũng cần xem xét một cách rõ ràng là tài khoản lưu trữ khóa, những tài khoản này 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 điều này một cách hiệu quả có thể yêu cầu L2 hỗ trợ các mã opcode 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 tài khoản trên L2 hỗ trợ các thao tác 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ợ giao dịch trừu tượng tài khoản, trong thực tế, nhu cầu về danh sách bao gồm và nhu cầu về bể nhớ phi tập trung thực sự rất giống nhau, mặc dù tính linh hoạt đối với danh sách bao gồm có phần lớn hơn. Hơn nữa, việc triển khai trừu tượng tài khoản nên được thực hiện càng nhiều càng tốt giữa L1 và L2. Nếu trong tương lai chúng ta mong đợi hầu hết người dùng sử dụng Rollup lưu trữ khóa, thiết kế trừu tượng tài khoản nên dựa trên điều này.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Cải tiến EIP-1559
) Nó giải quyết 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 trung bình để bao gồm khối. Tuy nhiên, việc thực hiện EIP-1559 hiện tại vẫn không hoàn hảo ở nhiều khía cạnh:
Công thức có một số thiếu sót: nó không nhằm mục tiêu 50% khối, mà là khoảng 50-53% khối đầy đủ, điều này phụ 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" (.
Trong những trường hợp cực đoan, điều chỉnh không đủ nhanh.
Công thức )EIP-4844( được sử dụng cho blobs ở phía sau được thiết kế đặc biệt để giải quyết vấn đề đầu tiên, nhìn chung cũng đơn giản hơn. Tuy nhiên, 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 tạm thời hỗn loạn, liên quan đến hai cơ chế khác nhau, và có một quan điểm cho rằng, theo thời gian, cả hai đều cần phải được cải tiến.
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 việc đ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 tồi tệ nhất: giá tài nguyên trong Ethereum phải được đặt để xử lý trường hợp tồi tệ nhất, tức là toàn bộ mức tiêu thụ gas của một khối chiếm một tài nguyên, nhưng mức sử dụng trung bình thực tế thấp hơn nhiều, dẫn đến sự kém hiệu quả.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) Đa chiều Gas là gì, nó hoạt động như thế nào?
Giải pháp cho những vấn đề không hiệu quả này là Gas đa chiều: thiết lập 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 về mặt kỹ thuật độc lập với EIP-1559, nhưng EIP-1
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
14 thích
Phần thưởng
14
7
Chia sẻ
Bình luận
0/400
MissedAirdropBro
· 07-26 03:16
Tại sao lại là trừu tượng hóa tài khoản nữa!
Xem bản gốcTrả lời0
BrokenDAO
· 07-25 06:25
Một lộ trình đầy tham vọng nữa, kết cục có khả năng cao vẫn sẽ lặp lại số phận của Casper.
Xem bản gốcTrả lời0
GasGuru
· 07-24 20:52
Nghe có vẻ đáng tin đấy.
Xem bản gốcTrả lời0
SigmaBrain
· 07-24 20:51
Cái gì vậy, phiên bản này lại phải sửa đổi.
Xem bản gốcTrả lời0
OPsychology
· 07-24 20:45
Ngày nào bản nâng cấp này sẽ được ra mắt?
Xem bản gốcTrả lời0
WalletWhisperer
· 07-24 20:31
các mô hình hành vi cho thấy evm2.0 sẽ kích hoạt các cuộc di cư ví hàng loạt... thống kê là điều không thể tránh khỏi
Xem bản gốcTrả lời0
Whale_Whisperer
· 07-24 20:29
EVM nâng cấp sớm nên được đề xuất rồi, phí gas này thật sự không chịu nổi.
Tương lai của giao thức Ethereum: Nâng cấp EVM, trừu tượng hóa tài khoản và tối ưu hóa phí
Hướng phát triển tương lai của giao thức Ethereum: Chương thịnh vượng
Trong thiết kế giao thức Ethereum có nhiều "chi tiết" quan trọng quyết định sự thành công của nó. Khoảng một nửa nội dung liên quan đến các loại cải tiến EVM khác nhau, phần còn lại bao gồm nhiều chủ đề ngách khác nhau, đó chính là ý nghĩa của "thịnh vượng".
Thịnh vượng: Mục tiêu chính
Cải tiến EVM
Đã giải quyết vấn đề gì?
Hiện tại, EVM khó khăn trong việc phân tích tĩnh, điều này làm cho việc tạo ra các triển khai hiệu quả, xác minh chính thức mã và thực hiện mở rộng thêm trở nên khó khăn. Ngoài ra, hiệu suất của EVM thấp, khó khăn trong việc thực hiện nhiều hình thức mật mã cao cấp, trừ khi được hỗ trợ rõ ràng thông qua việc biên dịch trước.
Nó là gì, 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 trong đợt phân tách cứng tiếp theo. EOF là một loạt EIP, xác định một phiên bản mã EVM mới với nhiều đặc điểm độc đáo, nổi bật nhất là:
Cấu trúc mã EOF bao gồm đoạn mã, đoạn dữ liệu và đoạn thông tin kiểu.
Khi giới thiệu EOF, việc nâng cấp thêm trở nên dễ dàng hơn, hiện tại sự phát triển hoàn thiện nhất là mở rộng số học mô-đun EVM ( EVM-MAX ). EVM-MAX tạo ra một tập hợp các lệnh mới chuyên biệt cho phép tính toán mô-đun và đặt chúng vào một không gian bộ nhớ mới không thể truy cập bởi các mã lệnh khác, điều này cho phép sử dụng các 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 tính SIMD (Single Instruction Multiple Data) (. SIMD có thể được sử dụng để tăng tốc nhiều hình thức mật mã, bao gồm hàm băm, STARKs 32 bit và mật mã dựa trên lưới, sự kết hợp giữa EVM-MAX và SIMD khiến cho hai loại mở rộng hướng đến hiệu suất này trở thành một cặp tự nhiên.
) Liên kết nghiên cứu hiện có
Công việc còn lại và sự cân nhắc
Hiện tại, EOF dự kiến sẽ được đưa vào trong hard fork tiếp theo. Mặc dù luôn có khả năng loại bỏ nó vào phút chót, nhưng việc làm như vậy sẽ gặp nhiều thách thức lớn. Việc loại bỏ EOF có nghĩa là bất kỳ bản nâng cấp nào của EVM trong tương lai sẽ cần được thực hiện mà không có EOF, mặc dù có thể làm được, nhưng có thể sẽ khó khăn hơn.
Sự đánh đổi chính của EVM nằm ở độ phức tạp của L1 và độ phức tạp của cơ sở hạ tầng, EOF là một lượng lớn mã cần được thêm vào việc triển khai EVM, kiểm tra mã tĩnh cũng tương đối 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à nhiều lợi ích khác. Có thể nói, lộ trình ưu tiên cải tiến liên tục Ethereum L1 nên bao gồm và xây dựng dựa trên EOF.
Công việc quan trọng cần thực hiện là triển khai chức năng tương tự như EVM-MAX cộng với SIMD, và tiến hành kiểm tra hiệu suất tiêu thụ gas của các hoạt động mã hóa khác nhau.
Làm thế 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 mình để L2 cũng có thể dễ dàng thực hiện điều chỉnh tương ứng, nếu hai bên không thực hiện điều chỉnh đồng bộ, có thể gây ra sự không tương thích, mang lại ảnh hưởng tiêu cực. Ngoài ra, EVM-MAX và SIMD có thể giảm chi phí gas của nhiều hệ thống chứng minh, từ đó làm cho L2 hiệu quả hơn. Nó cũng giúp việc thay thế nhiều mã biên dịch trước bằng mã EVM có thể thực hiện cùng một nhiệm vụ trở nên dễ dàng hơn, có thể không ảnh hưởng đáng kể đến hiệu suất.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Trừu tượng tài khoản
) Giải quyết vấn đề gì?
Hiện tại, giao dịch chỉ có thể được xác thực bằng một cách: chữ ký ECDSA. Ban đầu, trừu tượng hóa tài khoản nhằm vượt qua điều này, cho phép logic xác thực của tài khoản là mã EVM tùy ý. Điều này có thể kích hoạt một loạt các ứng dụng:
Cho phép giao thức bảo mật hoạt động mà không cần trung gian, giảm đáng kể độ phức tạp của nó và loại bỏ một điểm phụ thuộc trung ương quan trọng.
Kể từ khi khái niệm trừu tượng tài khoản được đưa ra vào năm 2015, mục tiêu của nó cũng đã mở rộng để bao gồm nhiều "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 sở hữu một số ERC20 có thể sử dụng ERC20 để thanh toán gas.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Nó là gì, hoạt động như thế nào?
Cốt lõi của trừu tượng tài khoản là đơn giản: cho phép hợp đồng thông minh khởi xướng giao dịch, chứ không chỉ là EOA. Tất cả sự phức tạp đến từ việc thực hiện điều này theo cách thân thiện với việc duy trì mạng phi tập trung và ngăn chặn các cuộc tấn công từ chối dịch vụ.
Một thách thức chính điển hình là vấn đề sai lệch đa dạng: nếu có 1000 tài khoản có hàm xác minh đều phụ thuộc vào một giá trị duy nhất S, và giá trị S hiện tại khiến cho các giao dịch trong bộ nhớ hồ bơi đều hợp lệ, thì một giao dịch đơn lẻ lật ngược giá trị S có thể khiến tất cả các giao dịch khác trong bộ nhớ hồ bơi trở nên không hợp lệ. Điều này cho phép kẻ tấn công gửi các giao dịch rác đến bộ nhớ hồ bơi với chi phí rất thấp, từ đó làm tắc nghẽn tài nguyên của các nút mạng.
Sau nhiều năm nỗ lực, 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 đã đưa ra giải pháp để hiện thực hóa "trừu tượng tài khoản lý tưởng": ERC-4337.
Cách hoạt động của ERC-4337 là chia quá trình xử lý các 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 minh được xử lý trước, tất cả các thực thi sau đó được xử lý. Trong bộ nhớ, chỉ khi 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 họ và không đọc biến môi trường, thì mới được chấp nhận. Điều này có thể ngăn chặn các cuộc tấn công từ việc không thành công nhiều lần. Ngoài ra, cũng áp dụng các hạn chế gas nghiêm ngặt cho bước xác minh.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Liên kết nghiên cứu hiện có
) Công việc còn lại và sự cân nhắc
Hiện tại, vấn đề chính cần giải quyết là làm thế nào để hoàn toàn tích hợp trừu tượng hóa tài khoản vào giao thức. Gần đây, EIP trừu tượng hóa tài khoản được ưa chuộng là EIP-7701, đề xuất này thực hiện trừu tượng hóa tài khoản trên EOF. Một tài khoản có thể có một phần mã riêng biệt để xác thực, nếu tài khoản đó đã thiết lập phần mã này, thì phần mã đó sẽ được thực thi trong bước xác thực của giao dịch từ tài khoản đó.
Điều hấp dẫn của phương pháp này là nó rõ ràng chỉ ra hai quan điểm tương đương của trừu tượng tài khoản địa phương:
Nếu chúng ta bắt đầu từ việc đặt ra giới hạn nghiêm ngặt về độ phức tạp của mã có thể thực thi trong thời gian xác thực, thì tính an toàn của phương pháp này trở nên rất rõ ràng: chỉ cần thay thế xác thực ECDSA bằng việc thực thi mã EVM cần thời gian tương tự.
Tuy nhiên, theo thời gian, chúng ta cần nới lỏng những giới hạn này, vì việc cho phép các ứng dụng bảo vệ quyền riêng tư hoạt động mà không cần trung gian, cũng như khả năng kháng lại lượng tử là rất quan trọng. Để làm được điều này, chúng ta cần tìm ra những phương pháp 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 phải cực kỳ đơn giản.
Sự cân nhắc chính dường như là "viết nhanh một giải pháp mà ít người hài lòng" với "chờ đợi lâu hơn, có thể đạt được giải pháp lý tưởng hơn", phương pháp lý tưởng có thể là một phương pháp kết hợp. Một phương pháp kết hợp là viết nhanh một số trường hợp sử dụng và dành nhiều thời gian hơn để khám phá các trường hợp sử dụng khác. Một phương pháp khác là triển khai phiên bản trừu tượng tài khoản tham vọng hơn trên L2 trước tiên. Tuy nhiên, thách thức mà điều này đối mặt là đội ngũ L2 cần phải có niềm tin vào công việc của đề xuất để sẵn sàng thực hiện, đặc biệt là để đảm bảo rằng L1 và/hoặc các L2 khác trong tương lai có thể áp dụng các giải pháp tương thích.
Một ứng dụng khác mà chúng ta cũng cần xem xét một cách rõ ràng là tài khoản lưu trữ khóa, những tài khoản này 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 điều này một cách hiệu quả có thể yêu cầu L2 hỗ trợ các mã opcode 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 tài khoản trên L2 hỗ trợ các thao tác 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ợ giao dịch trừu tượng tài khoản, trong thực tế, nhu cầu về danh sách bao gồm và nhu cầu về bể nhớ phi tập trung thực sự rất giống nhau, mặc dù tính linh hoạt đối với danh sách bao gồm có phần lớn hơn. Hơn nữa, việc triển khai trừu tượng tài khoản nên được thực hiện càng nhiều càng tốt giữa L1 và L2. Nếu trong tương lai chúng ta mong đợi hầu hết người dùng sử dụng Rollup lưu trữ khóa, thiết kế trừu tượng tài khoản nên dựa trên điều này.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Cải tiến EIP-1559
) Nó giải quyết 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 trung bình để bao gồm khối. Tuy nhiên, việc thực hiện EIP-1559 hiện tại vẫn không hoàn hảo ở nhiều khía cạnh:
Công thức )EIP-4844( được sử dụng cho blobs ở phía sau được thiết kế đặc biệt để giải quyết vấn đề đầu tiên, nhìn chung cũng đơn giản hơn. Tuy nhiên, 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 tạm thời hỗn loạn, liên quan đến hai cơ chế khác nhau, và có một quan điểm cho rằng, theo thời gian, cả hai đều cần phải được cải tiến.
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 việc đ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 tồi tệ nhất: giá tài nguyên trong Ethereum phải được đặt để xử lý trường hợp tồi tệ nhất, tức là toàn bộ mức tiêu thụ gas của một khối chiếm một tài nguyên, nhưng mức sử dụng trung bình thực tế thấp hơn nhiều, dẫn đến sự kém hiệu quả.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) Đa chiều Gas là gì, nó hoạt động như thế nào?
Giải pháp cho những vấn đề không hiệu quả này là Gas đa chiều: thiết lập 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 về mặt kỹ thuật độc lập với EIP-1559, nhưng EIP-1