chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

我今天要講的就是最小驚訝原則，它有一個奇特的名字，但卻是一個非常簡單的想法。它所說的是，當呈現(xiàn)聲稱要做某件事的代碼時，大多數(shù)用戶都會假設它是如何完成這件事的。因此，作為開發(fā)人員，你的工作是編寫符合這些假設的代碼，這樣你的用戶就不會感到意外。

這是一個很好的原則，因為開發(fā)人員喜歡對事物進行假設。如果你導出一個名為calculateScore(GameState) 的函數(shù)，很多人就會假設該函數(shù)只會從游戲狀態(tài)中讀取。如果你還改變了游戲狀態(tài)，你會使得很多人面臨困惑的狀態(tài)，他們試圖弄清楚為什么他們的游戲狀態(tài)會隨機被破壞。即使你把它放在文檔中，仍然不能保證人們會看到它，所以最好首先確保你的代碼不會令人驚訝。

“6小時的調(diào)試工作，可以為你們節(jié)省5分鐘的文檔閱讀時間?！?/p>

1

越安全越好，對嗎？

早在 2018 年初，當ERC-721 標準被起草出來時，有人就提出了實施轉(zhuǎn)賬安全性?的建議，以確保代幣不會被卡在不用于處理代幣的接受者合約中。為此，提案作者修改了transfer函數(shù)的行為，以檢查接收方是否能夠支持代幣轉(zhuǎn)賬。他們還引入了unsafeTransfer函數(shù)，如果發(fā)送者愿意，該函數(shù)將繞過這個檢查。

然而，由于擔心向后兼容性，這個函數(shù)在隨后的提交中被重命名了。這使得ERC-20 和 ERC-721 代幣的transfer函數(shù)表現(xiàn)相同。但是，現(xiàn)在需要將接收方檢查轉(zhuǎn)移到其他地方。因此，標準作者就引入了safe類函數(shù)：safeTransfer 以及 safeTransferFrom。

這是一個關于正當性問題的解決方案，因為有許多 ERC-20 代幣被意外轉(zhuǎn)移到從未期望收到代幣的合約的例子（一個特別常見的錯誤是將代幣轉(zhuǎn)移到代幣合約中，將其永久鎖定）。而在起草 ERC-1155 標準時，提案作者從ERC-721標準汲取了靈感，不僅在轉(zhuǎn)賬時，而且在鑄造（mint）也納入了接收方檢查，這一點也不足為奇。

在接下來的幾年里，這些標準大多處于休眠狀態(tài)，而 ERC-20代幣標準保持了它的流行狀態(tài)，而最近gas成本的飆升，以及社區(qū)對NFT興趣的增強，自然而然導致開發(fā)者越來越多地使用ERC-721和ERC-1155代幣標準。有了這些新的興趣，我們應該慶幸這些標準的設計考慮了安全性，對嗎？

2

越安全越好，真的嗎？

Ok，但對于轉(zhuǎn)帳和鑄造來說，安全意味著什么呢？不同的當事人對安全有不同的解釋。對于開發(fā)人員來說，一個安全函數(shù)可能意味著它不包含任何bug或引入額外的安全問題。而對于用戶來說，這可能意味著它包含額外的護欄，以保護他們不被意外射中自己的腳。

事實證明，在這種情況下，這些函數(shù)更多的是后者，而較少會是前者。這是特別令人遺憾的，因為在transfer和safeTransfer函數(shù)之間進行選擇時，你為什么不選擇安全的那個函數(shù)呢？名字都體現(xiàn)出來了！

好吧，其中的一個原因可能是我們的老朋友reentrancy（可重入性），或者我一直在努力將其重命名為：不安全的外部調(diào)用?；叵胍幌?，如果接收方是攻擊者控制的，則任何外部調(diào)用都可能不安全，因為攻擊者可能會導致你的合約轉(zhuǎn)換為未定義狀態(tài)。根據(jù)設計，這些“安全”函數(shù)執(zhí)行對代幣接收者的外部調(diào)用，通常在鑄造或轉(zhuǎn)移期間由發(fā)送者控制。換句話說，這實際上是不安全外部調(diào)用的教科書示例。

但是，你可能會問自己，如果允許接收方合約拒絕他們無法處理的轉(zhuǎn)賬，那最壞的后果是什么？好吧，讓我通過兩個案例研究來回答這個問題。

3

例子1: Hashmasks

Hashmasks是一個供應有限的 NFT頭像項目，用戶每次交易最多可以購買 20 個mask NFT（盡管它們已經(jīng)售罄數(shù)月了）。下面是購買mask的函數(shù)：

你可能覺得這個函數(shù)看起來非常合理。然而，正如你可能已經(jīng)預料到的，在 _safeMint 調(diào)用中隱藏著一些險惡的東西。讓我們來看看。

為了安全性，這個函數(shù)對token的接受者執(zhí)行了一次callback回調(diào)，以檢查他們是否愿意接受轉(zhuǎn)賬。然而，我們是token的接收者，這意味著我們剛剛得到了一次callback回調(diào)，在這個點上我們可以做任何我們想做的事情，包括再次調(diào)用mintNFT函數(shù)。如果我們這樣做，我們將在僅鑄造了一個mask后重調(diào)用該函數(shù)，這意味著我們可以請求再鑄造另外19個mask。這導致最終鑄造出了39個 mask NFT，盡管規(guī)則允許鑄造的最大數(shù)量只有20個。

4

例子2: ENS域名封裝器

最近，來自ENS 的Nick Johnson聯(lián)系了我，他想讓我看看他們正在進行的ENS域名封裝器工作。這個域名封裝器允許用戶用新的ERC-1155 token代幣化他們的ENS域名，這提供了對細粒度權(quán)限以及更一致的 API 的支持。

概括地說，為了封裝任何ENS域名（更具體地說，除了 2LD.eth 之外所有的ENS域名），你必須首先批準域名封裝器以訪問你的ENS域名。然后，你調(diào)用wrap(bytes,address,uint96,address)，它既為你鑄造一個ERC-1155 token，也負責管理底層的ENS域名。

下面就是這個wrap函數(shù)，它相當簡單。首先，我們調(diào)用_wrap，它執(zhí)行一些邏輯并返回哈希域名。然后，我們確保交易發(fā)送方確實是ENS域名的所有者，然后再接管該域名。請注意，如果發(fā)送方不擁有底層的ENS域名，則整個交易應還原，撤銷在_wrap 中所做的任何更改。

下面是_wrap函數(shù)本身，這里沒有什么特別的。

不幸的是，正是這個 _mint 函數(shù)，它可能會給毫無戒心的開發(fā)者帶來可怕的驚喜。ERC-1155 規(guī)范規(guī)定，在鑄造token時，應咨詢接收者是否愿意接受該token。在深入研究庫代碼（該代碼庫根據(jù)OpenZeppelin的基礎稍作了修改）后，我們發(fā)現(xiàn)情況確實如此。

但這到底對我們有什么好處呢？好的，我們再一次看到了一個不安全的外部調(diào)用，我們可以用它來執(zhí)行重入攻擊。具體地說，請注意，在callback回調(diào)期間，我們擁有了代幣ENS域名的ERC-1155 token，但域名封裝器尚未驗證我們擁有基礎ENS域名本身。這使我們能夠在不實際擁有ENS域名的情況下對其進行操作。例如，我們可以要求域名封裝器解開我們的域名，燃燒掉我們剛剛鑄造的token并獲取底層的ENS域名。

現(xiàn)在我們擁有了底層的ENS域名，我們可以用它做任何我們想做的事情，比如注冊新的子域名或者設置解析器。完成后，我們只需退出callback回調(diào)。域名封裝器將和底層ENS域名的當前所有者（即我們）交互，并完成交易。就像那樣，我們已經(jīng)取得了域名封裝器被批準用于的任何ENS域名的臨時所有權(quán)，并對其進行了任意更改。

5

結(jié)論

令人驚訝的代碼可能會以災難性的方式破壞事物。在本文的兩個案例下，開發(fā)人員合理地假設safe函數(shù)類可以安全地使用，卻無意中增加了他們的攻擊面。隨著ERC-721和ERC-1155代幣標準變得越來越流行及廣泛，這類攻擊情況很可能會越來越頻繁。開發(fā)人員需要考慮使用safe類函數(shù)的風險，并確定外部調(diào)用如何與他們編寫的代碼進行交互。