Tương lai có thể của giao thức Ethereum (sáu): Thịnh vượng
Có một số điều khó phân loại, trong thiết kế giao thức Ethereum, nhiều "chi tiết" rất quan trọng cho sự thành công của Ethereum. 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 được cấu thành từ nhiều chủ đề ngách khác nhau, đó chính là ý nghĩa của "sự thịnh vượng".
Phồn thịnh: 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 sự trừu tượng hóa tài khoản vào giao thức, để 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
Vấn đề gì đã được giải quyết?
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 thực hiện hiệu quả, xác minh chính thức mã và 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 mật mã cao cấp, trừ khi được hỗ trợ rõ ràng thông qua biên dịch trước.
Nó là gì, 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 hard fork tiếp theo. EOF là một loạt EIP, xác định phiên bản mã EVM mới, có 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 ) đã được tách ra.
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 cơ chế lệnh con rõ ràng mới
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 có thể sẽ dần dần bị loại bỏ hợp đồng cũ ( và thậm chí có thể bị chuyển đổi cưỡng bức thành mã EOF ). Hợp đồng mới sẽ hưởng lợi từ việc nâng cao hiệu suất mà EOF mang lại - trước tiên là thông qua mã byte được thu nhỏ một chút nhờ tính năng subroutine, sau đó là các chức năng mới hoặc giảm chi phí gas đặc thù của EOF.
Sau khi giới thiệu EOF, việc nâng cấp trở nên dễ dàng hơn, hiện tại phát triển hoàn thiện nhất là mở rộng toán học EVM module ( EVM-MAX ). EVM-MAX đã tạo ra một bộ lệnh mới dành riêng cho phép 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ằng 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 như một khái niệm của Ethereum đã tồn tại từ rất lâu, được đề xuất lần đầu bởi Greg Colvin trong EIP-616. 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.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Một thiết kế tổng hợp EIP sẽ bắt đầu từ EIP-6690, sau đó:
Cho phép )i( bất kỳ số lẻ nào hoặc )ii( bất kỳ lũy thừa của 2 có giá trị lớn nhất là 2768 làm số mô đun.
Đối với mỗi mã lệnh EVM-MAX ) phép cộng, phép trừ, phép nhân (, thêm một phiên bản, phiên bản này không còn sử dụng 3 hằng số x, y, z, mà sử dụng 7 hằng số: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Trong mã Python, tác dụng của các mã lệnh này tương tự như:
python
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ế, điều này sẽ được xử lý theo cách song song.
Có thể thêm XOR, AND, OR, NOT và SHIFT) bao gồm vòng lặp và không vòng lặp (, ít nhất cho mô-đun lũy thừa của 2. Đồng thời thêm ISZERO) sẽ đẩy đầu ra vào ngăn xếp chính EVM(, điều này sẽ đủ mạnh để thực hiện mật mã đường elip, mật mã miền nhỏ) như Poseidon, Circle STARKs(, hàm băm truyền thống) như SHA256, KECCAK, BLAKE( và mật mã dựa trên lưới. Các nâng cấp EVM khác cũng có thể được thực hiện, nhưng cho đến nay vẫn chưa được quan tâm nhiều.
)# Công việc còn lại và sự đánh đổi
Hiện tại, EOF dự kiến sẽ được đưa vào 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 - đã có những chức năng bị tạm thời loại bỏ trong các hard fork trước, nhưng việc làm như vậy sẽ gặp phải nhiều thách thức. Việc loại bỏ EOF có nghĩa là bất kỳ nâng cấp nào trong tương lai cho EVM sẽ phải đượ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ự cân nhắc chính của EVM là sự phức tạp của L1 và sự phức tạp của 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, việc kiểm tra mã tĩnh cũng tương đối phức tạp. Tuy nhiên, đổi lại, chúng 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à hiện thực hóa các chức năng tương tự như EVM-MAX cộng 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 nó để L2 cũng có thể dễ dàng thực hiện các đ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 tác độ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 biên dịch trước bằng mã EVM có thể thực thi cùng một nhiệm vụ trở nên dễ dàng hơn, có thể không ảnh hưởng lớn đến hiệu suất.
Trừu tượng hóa tài khoản
Vấn đề gì đã được giải quyết?
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 tài khoản được thiết kế để 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ã chố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í nhiều chữ ký và ví phục hồi xã hội
Sử dụng một khóa để thực hiện các thao tác giá trị thấp, sử dụng một khóa khác ) hoặc một tập hợp khóa ( để thực hiện các thao tá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 tài khoản trừu tượng đượ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.
MPC) tính toán nhiều bên ( là một công nghệ đã có 40 năm lịch sử, được sử dụng để chia nhỏ khóa thành nhiều phần và lưu trữ trên nhiều thiết bị, tận dụng công nghệ mật mã để tạo ra chữ ký mà không cần phải kết hợp trực tiếp các phần khóa này.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
EIP-7702 là một đề xuất được lên kế hoạch giới thiệu trong lần phân tách cứng tiếp theo, EIP-7702 là kết quả của sự nhận thức ngày càng tăng về việc cung cấp sự tiện lợi của trừu tượng 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 (, nhằm cải thiện trải nghiệm của tất cả người dùng trong thời gian ngắn và tránh việc chia tách thành hai hệ sinh thái.
Công việc này bắt đầu từ EIP-3074 và cuối cùng hình thành EIP-7702. EIP-7702 cung cấp "chức 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 được sở hữu bên ngoài ngày hôm nay, tức là tài khoản được kiểm soát bởi chữ ký ECDSA(.
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 thông qua các công nghệ tiến bộ như tính toán đa bên hoặc EIP-7702, nhưng mục tiêu an ninh chính mà đề xuất trừu tượng tài khoản được đưa ra ban đầu chỉ có thể đạt được bằng cách truy ngược và giải quyết vấn đề gốc: cho phép mã hợp đồng thông minh kiểm soát xác thực giao dịch. Nguyên nhân chưa được thực hiện cho đến nay là việc triển khai an toàn, điều này là một thách thức.
)# 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. Toàn bộ 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 lưới phi tập trung và phòng ngừa 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 đề thất bại nhiều lần:
Nếu có 1000 hàm xác thực tài khoản phụ thuộc vào một giá trị duy nhất S, và giá trị S hiện tại khiến các giao dịch trong vùng nhớ đều hợp lệ, thì một giao dịch đơn lẻ đảo ngược giá trị S có thể khiến tất cả các giao dịch khác trong vùng nhớ 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 vùng nhớ 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 tính 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 việc xử lý các thao tác của người dùng thành hai giai đoạn: xác thực và thực thi. Tất cả các xác thực được xử lý trước, tất cả các thực thi sau đó sẽ được xử lý. Trong bộ nhớ, chỉ khi giai đoạn xác thực 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ừ chối dịch vụ. Ngoài ra, cũng áp dụng hạn chế gas nghiêm ngặt cho bước xác thực.
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 khách hàng Ethereum tập trung vào việc hợp nhất )Merge(, không có thêm năng lượng để xử lý các chức năng khác. Đó là lý do tại sao ERC-4337 sử dụng một đối tượng gọi là hành động 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 cần phải viết ít nhất một phần nội dung vào giao thức.
Hai lý do chính như sau:
EntryPoint như là tính không hiệu quả cố hữu của hợp đồng: mỗi gói khoảng 100.000 gas chi phí cố định, cùng với hàng nghìn gas bổ sung cho mỗi thao tác của người dùng.
Đảm bảo tính cần thiết của thuộc tính Ethereum: như danh sách chứa các đảm bảo cần được chuyển đến người dùng trừu tượng tài khoản.
Ngoài ra, ERC-4337 còn mở rộng hai chức năng:
Đại lý thanh toán ) Paymasters (: cho phép một tài khoản đại diện cho một tài khoản khác thanh toán phí, điều này vi phạm quy tắc chỉ tài khoản người gửi có thể được truy cập trong giai đoạn xác minh, do đó đã giới thiệu xử lý đặc biệt để đảm bảo tính an toàn của cơ chế đại lý thanh toán.
Giao thức ) Aggregators (: Hỗ trợ chức năng tổng hợp chữ ký, 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 cao nhất trên Rollup.
)# 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 đưa trừu tượng tài khoản vào giao thức, gần đây, trừu tượng tài khoản viết vào giao thức được ưa chuộng EIP là EIP-7701, đề xuất này thực hiện trừu tượng tài khoản trên EOF. Một tài khoản có thể sở hữu 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 đó.
Sự hấp dẫn của phương pháp này nằm ở chỗ nó rõ ràng chỉ ra hai góc nhìn tương đương của việc 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 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 cho độ phức tạp của mã có thể thực thi trong thời gian xác minh - không cho phép truy cập trạng thái bên ngoài, thậm chí giới hạn gas được thiết lập trong giai đoạn đầu cũng thấp đến mức không có hiệu lực đối với các ứng dụng chống lượng tử hoặc bảo vệ quyền riêng tư - thì tính an toàn của phương pháp này rất rõ ràng: chỉ cần thay thế xác minh 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 chống lại lượng tử đều rất quan trọng. Để làm điều này, chúng ta cần tìm ra 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 thực phải cực kỳ tối giản.
Sự cân nhắc chính dường như là "viết nhanh một giải pháp ít người hài lòng hơn" với "chờ đợi lâu hơn
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.
21 thích
Phần thưởng
21
5
Đăng lại
Chia sẻ
Bình luận
0/400
LonelyAnchorman
· 18giờ trước
EVM cái đồ chơi này khi nào mới mượt mà hơn chút...
Xem bản gốcTrả lời0
GateUser-2fce706c
· 08-16 09:03
Tận dụng cơ hội cải tiến EVM để lập một kế hoạch lớn... đã sớm dự đoán hướng phát triển này.
Xem bản gốcTrả lời0
PoetryOnChain
· 08-16 08:50
Sắp đến giới hạn rồi sao, V thần cuối cùng cũng đã hiểu ra.
Triển vọng tương lai của giao thức Ethereum: Cải tiến EVM và trừu tượng hóa tài khoản dẫn dắt sự thịnh vượng
Tương lai có thể của giao thức Ethereum (sáu): Thịnh vượng
Có một số điều khó phân loại, trong thiết kế giao thức Ethereum, nhiều "chi tiết" rất quan trọng cho sự thành công của Ethereum. 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 được cấu thành từ nhiều chủ đề ngách khác nhau, đó chính là ý nghĩa của "sự thịnh vượng".
Phồn thịnh: Mục tiêu chính
Cải tiến EVM
Vấn đề gì đã được giải quyết?
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 thực hiện hiệu quả, xác minh chính thức mã và 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 mật mã cao cấp, trừ khi được hỗ trợ rõ ràng thông qua biên dịch trước.
Nó là gì, 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 hard fork tiếp theo. EOF là một loạt EIP, xác định phiên bản mã EVM mới, có nhiều đặc điểm độc đáo, nổi bật nhất là:
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 có thể sẽ dần dần bị loại bỏ hợp đồng cũ ( và thậm chí có thể bị chuyển đổi cưỡng bức thành mã EOF ). Hợp đồng mới sẽ hưởng lợi từ việc nâng cao hiệu suất mà EOF mang lại - trước tiên là thông qua mã byte được thu nhỏ một chút nhờ tính năng subroutine, sau đó là các chức năng mới hoặc giảm chi phí gas đặc thù của EOF.
Sau khi giới thiệu EOF, việc nâng cấp trở nên dễ dàng hơn, hiện tại phát triển hoàn thiện nhất là mở rộng toán học EVM module ( EVM-MAX ). EVM-MAX đã tạo ra một bộ lệnh mới dành riêng cho phép 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ằng 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 như một khái niệm của Ethereum đã tồn tại từ rất lâu, được đề xuất lần đầu bởi Greg Colvin trong EIP-616. 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.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Một thiết kế tổng hợp EIP sẽ bắt đầu từ EIP-6690, sau đó:
python 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ế, điều này sẽ được xử lý theo cách song song.
)# Công việc còn lại và sự đánh đổi
Hiện tại, EOF dự kiến sẽ được đưa vào 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 - đã có những chức năng bị tạm thời loại bỏ trong các hard fork trước, nhưng việc làm như vậy sẽ gặp phải nhiều thách thức. Việc loại bỏ EOF có nghĩa là bất kỳ nâng cấp nào trong tương lai cho EVM sẽ phải đượ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ự cân nhắc chính của EVM là sự phức tạp của L1 và sự phức tạp của 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, việc kiểm tra mã tĩnh cũng tương đối phức tạp. Tuy nhiên, đổi lại, chúng 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à hiện thực hóa các chức năng tương tự như EVM-MAX cộng 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 nó để L2 cũng có thể dễ dàng thực hiện các đ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 tác độ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 biên dịch trước bằng mã EVM có thể thực thi cùng một nhiệm vụ trở nên dễ dàng hơn, có thể không ảnh hưởng lớn đến hiệu suất.
Trừu tượng hóa tài khoản
Vấn đề gì đã được giải quyết?
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 tài khoản được thiết kế để 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 tài khoản trừu tượng đượ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.
MPC) tính toán nhiều bên ( là một công nghệ đã có 40 năm lịch sử, được sử dụng để chia nhỏ khóa thành nhiều phần và lưu trữ trên nhiều thiết bị, tận dụng công nghệ mật mã để tạo ra chữ ký mà không cần phải kết hợp trực tiếp các phần khóa này.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
EIP-7702 là một đề xuất được lên kế hoạch giới thiệu trong lần phân tách cứng tiếp theo, EIP-7702 là kết quả của sự nhận thức ngày càng tăng về việc cung cấp sự tiện lợi của trừu tượng 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 (, nhằm cải thiện trải nghiệm của tất cả người dùng trong thời gian ngắn và tránh việc chia tách thành hai hệ sinh thái.
Công việc này bắt đầu từ EIP-3074 và cuối cùng hình thành EIP-7702. EIP-7702 cung cấp "chức 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 được sở hữu bên ngoài ngày hôm nay, tức là tài khoản được kiểm soát bởi chữ ký ECDSA(.
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 thông qua các công nghệ tiến bộ như tính toán đa bên hoặc EIP-7702, nhưng mục tiêu an ninh chính mà đề xuất trừu tượng tài khoản được đưa ra ban đầu chỉ có thể đạt được bằng cách truy ngược và giải quyết vấn đề gốc: cho phép mã hợp đồng thông minh kiểm soát xác thực giao dịch. Nguyên nhân chưa được thực hiện cho đến nay là việc triển khai an toàn, điều này là một thách thức.
)# 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. Toàn bộ 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 lưới phi tập trung và phòng ngừa 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 đề thất bại nhiều lần:
Nếu có 1000 hàm xác thực tài khoản phụ thuộc vào một giá trị duy nhất S, và giá trị S hiện tại khiến các giao dịch trong vùng nhớ đều hợp lệ, thì một giao dịch đơn lẻ đảo ngược giá trị S có thể khiến tất cả các giao dịch khác trong vùng nhớ 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 vùng nhớ 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 tính 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 việc xử lý các thao tác của người dùng thành hai giai đoạn: xác thực và thực thi. Tất cả các xác thực được xử lý trước, tất cả các thực thi sau đó sẽ được xử lý. Trong bộ nhớ, chỉ khi giai đoạn xác thực 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ừ chối dịch vụ. Ngoài ra, cũng áp dụng hạn chế gas nghiêm ngặt cho bước xác thực.
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 khách hàng Ethereum tập trung vào việc hợp nhất )Merge(, không có thêm năng lượng để xử lý các chức năng khác. Đó là lý do tại sao ERC-4337 sử dụng một đối tượng gọi là hành động 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 cần phải viết ít nhất một phần nội dung vào giao thức.
Hai lý do chính như sau:
Ngoài ra, ERC-4337 còn mở rộng hai chức nă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 đưa trừu tượng tài khoản vào giao thức, gần đây, trừu tượng tài khoản viết vào giao thức được ưa chuộng EIP là EIP-7701, đề xuất này thực hiện trừu tượng tài khoản trên EOF. Một tài khoản có thể sở hữu 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 đó.
Sự hấp dẫn của phương pháp này nằm ở chỗ nó rõ ràng chỉ ra hai góc nhìn tương đương của việc 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 cho độ phức tạp của mã có thể thực thi trong thời gian xác minh - không cho phép truy cập trạng thái bên ngoài, thậm chí giới hạn gas được thiết lập trong giai đoạn đầu cũng thấp đến mức không có hiệu lực đối với các ứng dụng chống lượng tử hoặc bảo vệ quyền riêng tư - thì tính an toàn của phương pháp này rất rõ ràng: chỉ cần thay thế xác minh 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 chống lại lượng tử đều rất quan trọng. Để làm điều này, chúng ta cần tìm ra 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 thực phải cực kỳ tối giản.
Sự cân nhắc chính dường như là "viết nhanh một giải pháp ít người hài lòng hơn" với "chờ đợi lâu hơn