Là một nhà phát triển Solidity có tư duy bảo mật, đây là dấu hiệu để bạn rất cẩn thận khi sử dụng các khối unchecked và inline assembly. Từ phiên bản 0.8.0 trở đi, trình biên dịch sẽ tự động xử lý các trường hợp tràn/thiếu. Nhưng điều gì sẽ xảy ra nếu một biến cho phép tràn sau đó được sử dụng trong yul? EVM thực sự không có khái niệm về các kiểu hẹp, vì vậy mã yul cấp thấp hoạt động trên kích thước từ 256-bit đầy đủ. Bạn có thấy điều này đang đi đến đâu không? Trong kịch bản được đơn giản hóa rất nhiều mà tôi đã gặp trong hợp tác hiện tại với @CyfrinAudits, biến length lặng lẽ tràn uint8 trong khối unchecked và quay lại 254 như mong đợi. Tuy nhiên, khi được sử dụng để thay đổi kích thước mảng trong khối inline assembly tiếp theo, các bit trên bẩn vẫn tồn tại như thể tràn chưa bao giờ xảy ra! Điều này dẫn đến độ dài của mảng lớn hơn nhiều so với mong đợi, mặc dù chúng ta có thể mong đợi nó bị giới hạn theo modulo giá trị tối đa có thể đại diện bởi biến length. Sử dụng trình gỡ lỗi foundry và cast --to-base <0xfe|0x01fe> dec, chúng ta có thể xác nhận rằng những giả định của chúng ta là sai và các bit trên thực sự vẫn bẩn khi ghi độ dài vào bộ nhớ. Mặc dù ví dụ này có thể được đơn giản hóa hơn nữa, điểm chính cần rút ra là luôn luôn nghi ngờ các khối unchecked/assembly và xem xét cách các bit trên của các kiểu hẹp có thể trở nên bẩn, ngay cả với một cái gì đó đơn giản trong yul như một phép gán. Điều này đôi khi có thể cảm thấy như một lỗi huyền bí mà không thể phát hiện nếu không có kiến thức sâu sắc về EVM và nội bộ trình biên dịch Solidity, vì vậy khi nhận ra điều gì đang xảy ra, tôi thấy ví dụ cụ thể này rất hữu ích. Hãy để lại cho tôi một bình luận bên dưới nếu bạn có bất kỳ câu hỏi nào, nhưng hy vọng bạn cũng thấy nó hữu ích!