Ý kiến: EVM không có phiên bản

Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ETHfans)Lưu ý của biên tập viên: Bài viết này đến từ

Những người đam mê Ethereum (ID: ETHfans)

, tác giả: Wei Tang, bản dịch: A Jian, được Odaily in lại với sự ủy quyền.

Nếu chúng tôi có cơ hội thiết kế lại EVM, cải thiện khả năng tương thích ngược của nó, làm cho nó thân thiện hơn với các bản nâng cấp tính năng và hoàn toàn bỏ qua hành lý lịch sử hiện có của chúng tôi, thì chúng tôi nên làm như thế nào?

Trong bài viết này, tôi khám phá câu hỏi này và ghi lại mô tả kỹ thuật và triết lý thiết kế đã phát triển từ nó.

tiêu đề phụ

Web không có phiên bản và đã tồn tại hàng thập kỷ. Vì vậy, ở đây tôi giả sử rằng chúng tôi muốn tạo một EVM không có sự khác biệt về phiên bản.

Chúng tôi cũng muốn đảm bảo rằng máy ảo này có khả năng tương thích ngược tốt (đây là thuộc tính bắt buộc). Điều đó có nghĩa là, ít nhất nó có thể tương thích tốt với các hợp đồng hiện có của chúng tôi (trong EVM hiện tại, ngay cả một sự thay đổi về mức tiêu thụ gas của một mã hành động có thể phá vỡ hợp đồng hiện có) và có thể dễ dàng thêm các chức năng mới.

tiêu đề phụ

opcode không hợp lệ

• Thay đổi đơn giản nhất và có thể là quan trọng nhất để thiết kế EVM liên tục là thêm quy trình xác minh để triển khai hợp đồng. Không phải tất cả các chuỗi byte đều là mã EVM hợp lệ và bất kỳ mã thao tác không hợp lệ nào cũng không được triển khai vào chuỗi, vì trong tương lai, các mã này có thể được gán một mã thao tác mới với chức năng khác.

• Các chi tiết kỹ thuật của cuộc kiểm tra này lần đầu tiên được ghi lại trong EIP-1712. Tóm lại, trước khi thực hiện chức năng chuyển đổi trạng thái do hợp đồng tạo ra (hoặc thêm mã hợp đồng vào trạng thái), các kiểm tra sau được thực hiện:

• Duyệt mã byte của mã

• Nếu mã là opcode PUSH(n), bỏ qua n byte tiếp theo

Nếu không, một lỗi sẽ bị bắt (bẫy)

Kiểm tra ở trên hơi giống với kiểm tra đích nhảy. Lưu ý rằng đối với các trường hợp ngoại lệ, chúng tôi đang sử dụng "bẫy" ở đây, chúng tôi sẽ giải thích chi tiết bên dưới.

tiêu đề phụ

Thăm dò tính năng

• Nếu EVM là để giải quyết các khác biệt về phiên bản, thì việc thực thi mã dựa trên EVM sẽ có khả năng điều tra xem môi trường cơ bản có hỗ trợ một tính năng cụ thể hay không. Với vai trò của EVM, chúng tôi luôn hy vọng rằng chức năng của một opcode đã được xác định có thể không thay đổi và các opcode mới có thể được giới thiệu để thêm chức năng. Và một số hợp đồng có thể đã được triển khai trước khi giới thiệu một số chức năng nhất định. Các hợp đồng này có thể lên lịch cho một chương trình con dự phòng để chạy khi một tính năng không được EVM hỗ trợ và bắt đầu sử dụng tính năng mới ngay khi hard fork kích hoạt. Thành phần điều tra chức năng giống như jumper sẽ được sử dụng ở đây.

• Opcode này có một đối số ngăn xếp. Nó kiểm tra xem tham số có nằm trong khoảng từ 0 đến 2^8 hay không và bắt lỗi nếu không

Nếu đối số (được hiểu là mã lệnh) không được hỗ trợ, hãy đẩy 0x0 trở lại ngăn xếp; nếu không thì đẩy 0x1

Ngoại lệ và bẫy

Trong quá trình hoạt động của EVM, có thể có nhiều yếu tố gây ra lỗi thực thi (fail). Một giao dịch đơn lẻ có thể không thành công do cạn kiệt gas; mỗi lớp trong ngăn xếp cuộc gọi có thể không thành công riêng lẻ và các lỗi của nó phải được xử lý rõ ràng bởi khung cuộc gọi chính. Các tính năng này mang lại cho chúng tôi một mức độ linh hoạt nhất định, nhưng chúng không nhất thiết là một điều tốt cho các hợp đồng chạy trên chuỗi khối. Ở đây, chúng tôi muốn xác định lại rằng bất kỳ ngoại lệ nào do chính EVM đưa ra đều có thể có hành vi bẫy để thay thế cho lỗi. Điều đó có nghĩa là, có thể có bẫy trong tất cả các lần thực thi khung gọi, khi bất kỳ loại gas nào được tiêu thụ hoặc ngay cả khi chức năng trạng thái hiện tại được khôi phục và thay đổi. Sau đó, các hợp đồng được khuyến khích sử dụng các giá trị trả về khi chúng muốn giao tiếp các lỗi không nghiêm trọng với người gọi cha của chúng.

tiêu đề phụ