Table of Contents
1. Các Tính Năng Mới Đáng Chú Ý
1.1. Bộ chuyển đổi stack-to-memory luôn được kích hoạt qua IR
Phiên bản phát hành này giải quyết vấn đề về việc mã được tạo ra bởi luồng sản xuất dựa trên IR mà thường dẫn đến lỗi “Stack Too Deep”. Điều này nhằm giúp các công cụ như bộ gỡ lỗi debuggers, vốn kém hiệu quả khi làm việc với mã tối ưu hóa.
Bản phân khúc cũ thường có thể tránh việc hết chỗ trong stack (stack là ngăn xếp trong EVM) ngay cả ở chế độ không tối ưu code, nhưng điều này đi kèm với mức phức tạp cao hơn vì nhiều tối ưu hóa đã được code cứng luôn trong quá trình tạo code. Bản phân khúc mới được thiết kế từ đầu với mục tiêu phân tách hai vấn đề này. Nó tạo ra đầu ra đơn giản nhưng rất không hiệu quả, được dự định sẽ được tinh chỉnh từng bước bằng bộ tối ưu hóa Yul. Sự biến đổi được thực hiện bởi từng bước có thể được kiểm tra và lập luận một cách riêng lẻ. Khuyết điểm của phương pháp này là mã không được tối ưu thường có rất nhiều biến cục bộ không được sử dụng và gặp vấn đề về stack.
Giải pháp của chúng tôi là đưa mã không tối ưu qua các biến đổi giúp giải quyết vấn đề stack nhưng không thay đổi mã một cách đáng kể như quá trình tối ưu hóa đầy đủ. Cụ thể, compiler sẽ chạy bước tối ưu hóa UnusedPruner trên mã như vậy để loại bỏ các biến không sử dụng. Ngoài ra, cơ chế chuyển đổi từ ngăn xếp sang bộ nhớ (stack-to-memory mover) bây giờ luôn được kích hoạt, giải quyết vấn đề ngăn xếp còn lại, tuy có thêm thao tác truy cập bộ nhớ.
Cả hai điều này đã có thể được thực hiện thông qua các cài đặt tối ưu hóa hiện có nhưng không phải là phần của hành vi mặc định. Mặc dù kỹ thuật có liên quan đến modul tối ưu hóa, chúng tôi coi chúng là một phần cần thiết của bản phân khúc mới và cơ sở dữ liệu mới cho việc mã không tối ưu.
1.2. Các Sửa Lỗi Quan Trọng
- Luôn tạo mã cho biểu thức trong <expression>.selector trong bản phân khúc tạo mã cũ. Bạn có thể đọc thêm về nó trong bài viết trên blog của chúng tôi ở đây.
- Bộ tối ưu hóa Yul: Sửa bước FullInliner (i) không bảo toàn thứ tự đánh giá của các đối số được truyền vào các hàm được nhúng vào trong mã không ở dạng chia thành biểu thức (nghĩa là khi sử dụng chuỗi tối ưu hóa tùy chỉnh mà bước không được tiếp theo bởi ExpressionSplitter (x)). Bạn có thể đọc thêm về nó trong bài viết trên blog của chúng tôi ở đây: https://soliditylang.org/blog/2023/07/19/full-inliner-non-expression-split-argument-evaluation-order-bug
1.3. Các Tính Năng Ngôn Ngữ
- Cho phép truy cập đã được xác minh vào các sự kiện từ các hợp đồng khác.
- Giảm bớt các hạn chế về việc khởi tạo biến không thay đổi. Việc đọc và ghi có thể xảy ra ở bất kỳ điểm nào trong thời gian xây dựng ngoài các hàm và bộ điều chỉnh. Việc khởi tạo tường minh không còn bắt buộc nữa.
1.4. Truy cập đã được xác minh vào các sự kiện từ hợp đồng khác
Solidity 0.8.21 cho phép truy cập vào các sự kiện được xác định trong các hợp đồng và giao diện mà hợp đồng hiện tại không kế thừa từ đó. Kết quả, ví dụ sau đây sẽ được biên dịch mà không có lỗi:
library L { event EL(); }
interface I { event EI(); }
contract C { event EC(); }
contract D { event ED(); }
contract E is D {
event EE();
function foo() public {
emit L.EL();
emit I.EI(); // Not allowed on 0.8.20
emit C.EC(); // Not allowed on 0.8.20
emit ED();
emit EE();
}
}
Việc này trước đây bị cấm do giới hạn của định dạng JSON NatSpec, một phần của siêu dữ liệu hợp đồng. Định dạng xác định sự kiện bằng chữ ký của chúng, bao gồm chỉ tên không đủ điều kiện và chỉ cho phép một phần NatSpec được xác định. Vì sự kiện được xác định có cùng chữ ký được xác định trong các hợp đồng khác nhau đại diện cho cùng một sự kiện trong giao diện ứng dụng (ABI), giải pháp chính xác là bao gồm NatSpec liên quan đến tất cả các định nghĩa có sẵn, nhưng thay đổi như vậy không tương thích ngược và phải chờ đến khi có một phiên bản mới.
Trong lúc chờ đợi, hạn chế này đã gây ra vấn đề về tính sử dụng cho người dùng ngôn ngữ nên chúng tôi đã quyết định bỏ qua nó một cách tùy ý bằng cách bỏ qua NatSpec của một trong các sự kiện. Trong trường hợp xung đột, NatSpec của định nghĩa có mặt trong hợp đồng hiện tại hoặc hợp đồng khác trong dãy thừa kế của nó sẽ được ưu tiên. Điều này sẽ được sửa chữa với sự giới thiệu của NatSpec v2.
Giảm bớt các hạn chế về việc khởi tạo biến không thay đổi Với các lỗi đã được tìm thấy trong vài tháng qua, khi kiểm tra việc khởi tạo không thay đổi không đạt đủ, do đó cho phép một số trường hợp biên giới nơi biến không thay đổi đó có thể không được khởi tạo (ví dụ: nhánh của các khối try/catch, vòng lặp, v.v.), bản nâng cấp này đã quyết định giảm bớt các hạn chế về việc khởi tạo không thay đổi một cách đáng kể.
….(còn tiếp)…
Digital Marketing Specialist