作為一個注重安全的Solidity開發者，這是你在使用unchecked區塊和內聯匯編時要非常小心的信號。 從0.8.0及之後的版本開始，編譯器會自動處理下溢/上溢。但如果一個允許上溢的變量隨後在yul中使用，會發生什麼呢？ EVM實際上沒有狹窄類型的概念，因此低級yul代碼在完整的256位字大小上操作。你能看出這將如何發展嗎？ 在我目前的@CyfrinAudits項目中遇到的這個高度簡化的場景中，長度變量在unchecked區塊中悄悄地上溢到uint8，並如預期那樣回繞到254。 然而，當用於在隨後的內聯匯編塊中調整數組大小時，骯髒的高位位仍然存在，彷彿上溢從未發生過！ 這導致數組的長度遠大於預期，即使我們可能期望它被限制在長度變量可表示的最大值的模數內。 使用foundry調試器和cast --to-base <0xfe|0x01fe> dec，我們可以確認我們的假設是錯誤的，確實在將長度寫入內存時高位位仍然保持骯髒。 雖然這個例子可以進一步簡化，但關鍵的收穫是要始終對unchecked/assembly塊保持高度懷疑，並考慮狹窄類型的高位位如何可能變得骯髒，即使在yul中像賦值這樣簡單的操作也是如此。 這有時可能感覺像是一個難以發現的深奧錯誤，除非對EVM和Solidity編譯器內部有深入的了解，因此一旦意識到發生了什麼，我發現這個具體的例子非常有幫助。 如果你有任何問題，請在下面留言，但希望你也覺得這很有幫助！