更好更安全的使用體驗
以太坊改進提案-3074允許EOA(外部擁有帳戶)將控制權轉移給指定的合約,從而獲得與合約相同的豐富執行能力。在 以太坊改進提案-3074 之前,EOA 每筆交易只能執行一個操作,例如批准 ERC20 或在 Uniswap 上交換。在以太坊改進提案-3074之後,EOA可以同時執行多個操作,甚至可以完成以前無法想像的任務。簡單來說,以太坊改進提案-3074大大提升了用戶體驗,熟悉的令牌授權方式將被重塑,在不改變用戶體驗的情況下增加安全性。
此外,通過以太坊改進提案-3074,EOA無需多方自行向鏈上發送交易,省去了籌集二餅支付交易費用的麻煩。
能夠獲得 EOA 控制權的合約稱為 Invoker 合約。當然,並不是任何合約都可以獲得對EOA的控制權:EOA必須使用私鑰簽名,簽名的內容將明確指定它是哪個Invoker合約以及允許Invoker執行哪些操作。
EOA 簽名內容將明確指定哪個調用方合約(調用方位址)並授權該調用方合約的操作(提交)
實際的執行過程可能如下所示:
注1:中繼器不是必需的。愛麗絲還可以將自己的標誌性內容和印章帶到鏈條上。
調用方驗證簽名並開始執行操作后,將作為 Alice EOA 執行,這就像獲得 EOA 的(有限)控制權。
但需要注意的是,EOA 的nonce值在執行後不會增加,所以同一個簽名可能會被重用(多EOA nonce保持不變),所以調用方需要實現自己的nonce機制來避免重放。
如果調用程式合約不是防重放的,則可以始終執行相同的授權。
有關以太坊改進提案-3074實際運行機制的介紹,請參閱:EIP3074簡介
多個事務的執行合併為一個,節省多個授權簽名的過程和一些Gas成本。
注意:這將要求 dApp 還支撐 Batchcall 函數,例如 以太坊改進提案-5792,該函數目前正在由社區推送。否則,如果dApp將使用者視為正常的EOA,則只會提示使用者為每個操作簽名一次。
在某些情況下,使用者還可以允許第三方代表他們執行操作。下圖中的委託金鑰是授權的第三方;訪問策略是執行限制,例如限制其只能操作 Uniswap、每天最多傳輸 1 二餅、授權有效期等。這些條件是在調用程式協定中設計和檢查的。檢查通過多,第三方可以作為使用者的EOA執行操作。
電報機器人可以被授予代表使用者的EOA執行操作的特定許可權
多只要滿足條件(即許可證簽名是合法的),就可以作為授權人EOA進行二餅轉讓,達到本地二餅許可證的效果。
使用者填寫限制單子條件,當滿足條件時,可以作為使用者EOA執行,包括批准代幣去中心化交易所、去去中心化交易所贖回等。 與去中心化交易所本身提供的限價交易相比,使用者不需要提前向去中心化交易所發送交易進行審批。
當 Alice 完成單子時,她將同時執行審批,無需事先審批。
如果條件被設計得更通用,它將變得像一個意圖合約:多只要滿足使用者指定的條件,任何人都可以以他們的EOA的名義執行意圖。
只要滿足意圖條件多,任何人都可以以使用者EOA的名義啟動執行
當使用者丟失EOA私鑰時,她(Alice)可以使用她簽署的以太坊改進提案-3074授權,以及她的授權人(丈夫和信託代理人)的簽名來轉移EOA的所有資產。實際上,收回的是(可轉讓的)資產,而不是帳戶控制權。EOA 私鑰丟失後,EOA 將無法多方使用。
當使用者丟失EOA私鑰時,其他授權人可以簽署並授權EOA資產的轉讓。
改進令牌授權方法,並可能取代批准/許可?
目前,dApp 的設計假設使用者是 EOA:用戶必須為 dApp 合同“預先批准”和“批准足夠的金額”。這意味著使用者不需要一直保持在線,等待dApp執行,或者不斷重新批准,大大改善了用戶體驗。對於限價單或平均成本法(DCA)等條件觸發的應用,使用者在滿足條件時可能無法在線,因此需要預先批准足夠大的資金才能執行 dApp 合約,並且可能是一個重複的過程。
用戶必須提前為dApp批准足夠大的金額,以便dApp可以用其資金運營。
但也有必要信任dApp或避免批准假dApp,並能夠立即刪除批准
後來出現的許可模式,比如代幣原生的 以太坊改進提案-2612 或者非原生的 Permit2,都是為了提升審批模式的使用體驗和安全性:使用者無需多方審批大量資金到每個 dApp 合約(每個代幣必須審批一次)。相反,使用者只需要“簽名”,授權dApp合約在“指定時間”內“提取指定金額”。這不僅大大減少了攻擊面,而且大大增強了用戶體驗。
使用者只需簽署鏈下,並可以指定金額和有效期,提供比批准更好的用戶體驗和安全性。
但事實上,不僅批准,許可模式也經常被用作詐騙攻擊方法(1,2,3):受害者錯誤地簽署了他們認為是dApp的許可證,但實際上卻給了攻擊者。
當使用者簽署許可證時,他們只能看到授權誰,但他們不知道哪些操作將與它配對執行。
注意:目前的許可證設計與重複操作的dApp不相容,例如平均成本法(DCA)或其他常規支付應用程式。這是因為許可證具有重播保護機制,因此一旦轉移完成,相同的許可證就不能再次使用,這意味著用戶必須提前簽署許可證,以便以後每次重複操作。
然而,以太坊改進提案-3074帶來了改變的機會:當dApp開發者知道EOA可以通過Invoker進行各種複雜的操作時,dApp交互的設計不需要多方犧牲安全性單子來改善用戶體驗,比如“使用者預批大筆資金”和“使用者簽署許可消息授權提現”。相反,使用者將 dApp 操作綁定到通過調用程式批准和執行原子執行:批准和 dApp 操作要麼一起成功執行,要麼一起失敗。僅批准是不可能成功的,因此使用者可以確信此批准適用於此操作。並且使用者使用的是鏈下簽名授權,所以用戶體驗和許可是一樣的!這意味著dApp多方不需要許可模式!未來,錢包可以直接禁止或對許可簽名請求進行更嚴格的審核,而不必擔心是否會導致使用者不使用某些dApp(反而被用於詐騙)。
用戶沒有多方簡單地授權某個位址,而是授權某個位址和做什麼,甚至可以看到類比的執行結果。
注意:這並不意味著可以完全阻止詐騙!使用者可能仍然會被騙進詐騙網站,詐騙網站仍然可以組織批准或轉帳操作供用戶簽名,但此時使用者至少可以看到這個簽名要做什麼,錢包甚至可以模擬顯示執行結果並呈現給使用者,這樣使用者就可以清楚地知道誰會損失多少錢,誰會獲得多少錢。與不知道什麼操作甚至執行結果的許可證相比,用戶有更多的資訊來決定是否授權。雖然這不是一個完美的治療方法,但它仍然是對目前情況的實質性改善。
目前的以太坊改進提案-3074設計會在簽名內容中包含EOA nonce值,因此多EOA將交易發送到鏈上執行並更改nonce值,所有原始以太坊改進提案-3074授權都將失效。
如果使用者授權其他人操作EOA,例如上面提到的會話密鑰或社交恢復方法,則必須防止EOA的nonce更改。否則,需要再次簽署所有授權並將其交給受託人,這對用戶體驗和機制的穩健性有相當大的影響。
如果使用者被授權自行操作,則無需特別阻止EOA nonce被更改,因為以太坊改進提案-3074簽名仍有望像交易一樣在某個截止日期之前執行。只是錢包需要管理EOA的更多以太坊改進提案-3074交易:如果有以太坊改進提案-3074個簽名等待上傳到鏈上,那麼EOA本身的交易將不得不等待。
注意:調用者合約本身會(並且應該)維護一套nonce機制,所以使用簽名后,無論EOA nonce是否發生變化,它仍然需要再次簽名。
會話密鑰和社會恢復很可能必須等到 以太坊改進提案-3074 更改規則以從簽名內容中刪除 EOA nonce,然後才能大規模採用。因此,錢包只需要關注“用戶授權操作”的用例,將以太坊改進提案-3074簽名視為交易。無需擔心避免EOA發送交易或更改EOA nonce。
但是需要注意的是,如果使用者想把自己的 以太坊改進提案-3074 簽名內容帶到鏈上,會有兩個缺點:
由於鏈將首先向 EOA nonce添加 1,因此 以太坊改進提案-3074 簽名的驗證將因 EOA nonce不匹配而失敗。
如果使用者在 以太坊改進提案-3074 簽名中的 EOA nonce添加 1,然後再將其帶到鏈上,驗證可以順利進行。
更好更安全的使用體驗
以太坊改進提案-3074允許EOA(外部擁有帳戶)將控制權轉移給指定的合約,從而獲得與合約相同的豐富執行能力。在 以太坊改進提案-3074 之前,EOA 每筆交易只能執行一個操作,例如批准 ERC20 或在 Uniswap 上交換。在以太坊改進提案-3074之後,EOA可以同時執行多個操作,甚至可以完成以前無法想像的任務。簡單來說,以太坊改進提案-3074大大提升了用戶體驗,熟悉的令牌授權方式將被重塑,在不改變用戶體驗的情況下增加安全性。
此外,通過以太坊改進提案-3074,EOA無需多方自行向鏈上發送交易,省去了籌集二餅支付交易費用的麻煩。
能夠獲得 EOA 控制權的合約稱為 Invoker 合約。當然,並不是任何合約都可以獲得對EOA的控制權:EOA必須使用私鑰簽名,簽名的內容將明確指定它是哪個Invoker合約以及允許Invoker執行哪些操作。
EOA 簽名內容將明確指定哪個調用方合約(調用方位址)並授權該調用方合約的操作(提交)
實際的執行過程可能如下所示:
注1:中繼器不是必需的。愛麗絲還可以將自己的標誌性內容和印章帶到鏈條上。
調用方驗證簽名並開始執行操作后,將作為 Alice EOA 執行,這就像獲得 EOA 的(有限)控制權。
但需要注意的是,EOA 的nonce值在執行後不會增加,所以同一個簽名可能會被重用(多EOA nonce保持不變),所以調用方需要實現自己的nonce機制來避免重放。
如果調用程式合約不是防重放的,則可以始終執行相同的授權。
有關以太坊改進提案-3074實際運行機制的介紹,請參閱:EIP3074簡介
多個事務的執行合併為一個,節省多個授權簽名的過程和一些Gas成本。
注意:這將要求 dApp 還支撐 Batchcall 函數,例如 以太坊改進提案-5792,該函數目前正在由社區推送。否則,如果dApp將使用者視為正常的EOA,則只會提示使用者為每個操作簽名一次。
在某些情況下,使用者還可以允許第三方代表他們執行操作。下圖中的委託金鑰是授權的第三方;訪問策略是執行限制,例如限制其只能操作 Uniswap、每天最多傳輸 1 二餅、授權有效期等。這些條件是在調用程式協定中設計和檢查的。檢查通過多,第三方可以作為使用者的EOA執行操作。
電報機器人可以被授予代表使用者的EOA執行操作的特定許可權
多只要滿足條件(即許可證簽名是合法的),就可以作為授權人EOA進行二餅轉讓,達到本地二餅許可證的效果。
使用者填寫限制單子條件,當滿足條件時,可以作為使用者EOA執行,包括批准代幣去中心化交易所、去去中心化交易所贖回等。 與去中心化交易所本身提供的限價交易相比,使用者不需要提前向去中心化交易所發送交易進行審批。
當 Alice 完成單子時,她將同時執行審批,無需事先審批。
如果條件被設計得更通用,它將變得像一個意圖合約:多只要滿足使用者指定的條件,任何人都可以以他們的EOA的名義執行意圖。
只要滿足意圖條件多,任何人都可以以使用者EOA的名義啟動執行
當使用者丟失EOA私鑰時,她(Alice)可以使用她簽署的以太坊改進提案-3074授權,以及她的授權人(丈夫和信託代理人)的簽名來轉移EOA的所有資產。實際上,收回的是(可轉讓的)資產,而不是帳戶控制權。EOA 私鑰丟失後,EOA 將無法多方使用。
當使用者丟失EOA私鑰時,其他授權人可以簽署並授權EOA資產的轉讓。
改進令牌授權方法,並可能取代批准/許可?
目前,dApp 的設計假設使用者是 EOA:用戶必須為 dApp 合同“預先批准”和“批准足夠的金額”。這意味著使用者不需要一直保持在線,等待dApp執行,或者不斷重新批准,大大改善了用戶體驗。對於限價單或平均成本法(DCA)等條件觸發的應用,使用者在滿足條件時可能無法在線,因此需要預先批准足夠大的資金才能執行 dApp 合約,並且可能是一個重複的過程。
用戶必須提前為dApp批准足夠大的金額,以便dApp可以用其資金運營。
但也有必要信任dApp或避免批准假dApp,並能夠立即刪除批准
後來出現的許可模式,比如代幣原生的 以太坊改進提案-2612 或者非原生的 Permit2,都是為了提升審批模式的使用體驗和安全性:使用者無需多方審批大量資金到每個 dApp 合約(每個代幣必須審批一次)。相反,使用者只需要“簽名”,授權dApp合約在“指定時間”內“提取指定金額”。這不僅大大減少了攻擊面,而且大大增強了用戶體驗。
使用者只需簽署鏈下,並可以指定金額和有效期,提供比批准更好的用戶體驗和安全性。
但事實上,不僅批准,許可模式也經常被用作詐騙攻擊方法(1,2,3):受害者錯誤地簽署了他們認為是dApp的許可證,但實際上卻給了攻擊者。
當使用者簽署許可證時,他們只能看到授權誰,但他們不知道哪些操作將與它配對執行。
注意:目前的許可證設計與重複操作的dApp不相容,例如平均成本法(DCA)或其他常規支付應用程式。這是因為許可證具有重播保護機制,因此一旦轉移完成,相同的許可證就不能再次使用,這意味著用戶必須提前簽署許可證,以便以後每次重複操作。
然而,以太坊改進提案-3074帶來了改變的機會:當dApp開發者知道EOA可以通過Invoker進行各種複雜的操作時,dApp交互的設計不需要多方犧牲安全性單子來改善用戶體驗,比如“使用者預批大筆資金”和“使用者簽署許可消息授權提現”。相反,使用者將 dApp 操作綁定到通過調用程式批准和執行原子執行:批准和 dApp 操作要麼一起成功執行,要麼一起失敗。僅批准是不可能成功的,因此使用者可以確信此批准適用於此操作。並且使用者使用的是鏈下簽名授權,所以用戶體驗和許可是一樣的!這意味著dApp多方不需要許可模式!未來,錢包可以直接禁止或對許可簽名請求進行更嚴格的審核,而不必擔心是否會導致使用者不使用某些dApp(反而被用於詐騙)。
用戶沒有多方簡單地授權某個位址,而是授權某個位址和做什麼,甚至可以看到類比的執行結果。
注意:這並不意味著可以完全阻止詐騙!使用者可能仍然會被騙進詐騙網站,詐騙網站仍然可以組織批准或轉帳操作供用戶簽名,但此時使用者至少可以看到這個簽名要做什麼,錢包甚至可以模擬顯示執行結果並呈現給使用者,這樣使用者就可以清楚地知道誰會損失多少錢,誰會獲得多少錢。與不知道什麼操作甚至執行結果的許可證相比,用戶有更多的資訊來決定是否授權。雖然這不是一個完美的治療方法,但它仍然是對目前情況的實質性改善。
目前的以太坊改進提案-3074設計會在簽名內容中包含EOA nonce值,因此多EOA將交易發送到鏈上執行並更改nonce值,所有原始以太坊改進提案-3074授權都將失效。
如果使用者授權其他人操作EOA,例如上面提到的會話密鑰或社交恢復方法,則必須防止EOA的nonce更改。否則,需要再次簽署所有授權並將其交給受託人,這對用戶體驗和機制的穩健性有相當大的影響。
如果使用者被授權自行操作,則無需特別阻止EOA nonce被更改,因為以太坊改進提案-3074簽名仍有望像交易一樣在某個截止日期之前執行。只是錢包需要管理EOA的更多以太坊改進提案-3074交易:如果有以太坊改進提案-3074個簽名等待上傳到鏈上,那麼EOA本身的交易將不得不等待。
注意:調用者合約本身會(並且應該)維護一套nonce機制,所以使用簽名后,無論EOA nonce是否發生變化,它仍然需要再次簽名。
會話密鑰和社會恢復很可能必須等到 以太坊改進提案-3074 更改規則以從簽名內容中刪除 EOA nonce,然後才能大規模採用。因此,錢包只需要關注“用戶授權操作”的用例,將以太坊改進提案-3074簽名視為交易。無需擔心避免EOA發送交易或更改EOA nonce。
但是需要注意的是,如果使用者想把自己的 以太坊改進提案-3074 簽名內容帶到鏈上,會有兩個缺點:
由於鏈將首先向 EOA nonce添加 1,因此 以太坊改進提案-3074 簽名的驗證將因 EOA nonce不匹配而失敗。
如果使用者在 以太坊改進提案-3074 簽名中的 EOA nonce添加 1,然後再將其帶到鏈上,驗證可以順利進行。