區塊鏈

之前的文章 Solidity 智能合約 - 工廠模式的重組問題 (Reorg) 說明了重組問題和解決方案，但是並不能防止搶先交易 (Front Running)。本篇文章將說明這個安全問題，以及解決方式。 搶先交易 (Front Running)這是區塊鏈常見的一種獲利手法，也可以說是一種攻擊，監控未確認的交易來預知未來將發生的事情，讓自己的交易搶先執行而獲利。例如看到有人要用大單買入 ETH，就搶先買入後抬高價格賣給他。 問題延續上一篇文章的情境： 使用者 A 用 salt 0xabcd... 建立一個多簽錢包 0x9876...。 使用者 A 轉入 ETH 到 0x9876...。 假設使用者 A 先預測了生成的錢包為 0x9876...，並連續送出第二筆交易。這時候在鏈上，存在這兩筆未確認交易，攻擊者看到後搶先送出他的交易： 攻擊者 C 用 salt 0xabcd... 建立一個多簽錢包 0x9876...。 使用者 A 用 salt 0xabcd... 建立一個多簽錢包 0x9876...。已存在，交易失敗。 使用者 A 轉入 ETH 到 0x9876...。 結果 E ...

之前的文章 Solidity 智能合約 - 工廠模式 (Factory Pattern) 和 Solidity 智能合約 - 地址生成規則說明了工廠模式和地址生成的規則。在了解這些之後我們會發現某些情況可能存在重組的問題，本篇文章將說明這個安全問題，以及解決方式。 重組 (Reorg)我們這裡只簡略的說明這個現象，簡單說就是區塊打包的結果有可能發生變動，造成原本執行交易的結果發生變化 問題在工廠模式中採用 create 的地址生成規則的時候，會和執行順序有關。我們考慮以下的模擬情境： 使用者 A 建立一個多簽錢包 0x1234...。 使用者 A 轉入 ETH 到 0x1234...。 使用者 B 建立一個多簽錢包 0x5678...。 由於發生重組，順序改變了： 使用者 B 建立一個多簽錢包 0x1234...。 使用者 A 建立一個多簽錢包 0x5678...。 使用者 A 轉入 ETH 到 0x1234...。 結果使用者 A 的 ETH 跑到使用者 B 建立的 0x1234... 解決方案等待區塊確認如同中心化交易所入金一樣，等待足夠多的區塊確認後再進行下一步，使用者 ...

之前的文章 Solidity 智能合約 - 工廠模式 (Factory Pattern) 說明了生成智能合約的方法，這篇文章進一步說明智能合約地址生成的規則，包含了 create 和 create2 的差異。 目前產生合約主要有兩種規則： create create2 create我們可以在智能合約中使用這個指令來建立合約，而上一篇文章提到的 new 寫法其實也是使用 create 指令。另外，EOA 錢包部署合約的時候也適用這個規則。這個規則中，影響地址主要是下面兩個參數： 發送者 (sender) nonce 生成的公式如下： 1keccak256(rlp([sender, nonce]))[12:] 後面的 [12:] 表示生成的 hash 取最後 20 bytes。如果是 EOA 錢包部署，sender 為錢包地址，nonce 為錢包發送交易時的 nonce。如果是智能合約中建立其他合約，sender 則為執行建立合約行為的主合約地址，nonce 則為此合約的第幾次執行生成合約，從 1 開始。 例如我在 hardhat 進行測試的時候，預設錢包是：0xf39Fd6e5 ...

簡介工廠模式 (Factory Pattern) 是一種程式設計的設計模式 (Design Pattern)，用來生成物件的一種方式。在智能合約開發中，有些情況會使用到。例如：Uniswap 的交易對或是生成 Token。只需要輸入一些不同的參數，像是名稱、總發行量之類的設定，就可以就快速部署功能相同的合約。我們可以透過智能合約中撰寫一些程式碼來產生新合約，本篇文章會介紹一些方法。 在智能合約中用來建立合約實例的指令有三種寫法： new create create2 而根據實作的方法主要分為兩種： 部署整份合約 使用 Proxy 部署整份合約先假設我們有一個這樣的合約 12345import "@openzeppelin/contracts/token/ERC20/ERC20.sol";contract NormalToken is ERC20 { constructor(string memory name_, string memory symbol_) ERC20(name_, symbol_) {}} ...

說明zkSync 可以使用 hardhat-zksync-verify 工具，來讓合約在瀏覽器上開源，通常可以使用下面指令進行驗證： 1npx hardhat verify --network zkSync 合約地址 例如使用合約地址 0xdD5AE451A75a654146747235FDB515F06A55D018，為一個 TransparentUpgradeableProxy 的合約，嘗試使用下面指令進行驗證： 1npx hardhat verify --network zkSync 0xdD5AE451A75a654146747235FDB515F06A55D018 結果會出現下面錯誤： 123Error in plugin @matterlabs/hardhat-zksync-verify: The number of constructor arguments you provided (0) does not match the number of constructor arguments the contract has been deployed with (3 ...

在之前的文章 Solidity - zkSync Paymaster 程式範例說明了如何撰寫和部署 Paymaster 合約，也有使用 Paymaster 發起交易的方法。不過專案是用 zksync-cli 建立，使用的是 Ethers.js v5 的版本。這篇文章會說明如何在 Web3.js 的專案中使用，本篇文章使用 Web3.js 4.2.2 版本。 zksync 套件zkSync 提供了官方的套件 zksync2-js 可以用來處理 Paymaster 相關的交易。但是該套件使用 Ethers.js 做為底層來開發，使用這套件等於要同時使用 Ethers.js。我這裡依據官方原始碼改寫了一份 Web3.js 版本的，可直接加入專案使用，就不用和 Ethers.js 混合使用。例如儲存為 paymaster-utils.ts： 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686 ...

在前一篇文章 Solidity - zkSync Paymaster 程式範例說明了如何撰寫和部署 Paymaster 合約，也有使用 Paymaster 發起交易的方法。不過專案是用 zksync-cli 建立，使用的是 Ethers.js v5 的版本。這篇文章會以如何在 Dapp 中，使用現成 Paymaster 的角度來說明。包含 Ethers.js v5 和 v6 的用法。 使用 zksync 套件和連接錢包等說明，參考之前的文章使用 Ethers.js 操作 zkSync 帳戶抽象，這邊不重複說明。 產生 Paymaster 參數使用 Paymaster 發送交易要在交易中帶入 Paymaster 相關參數，可以使用套件中提供的方法： 1utils.getPaymasterParams(paymasterAddress: string, paymasterInput: PaymasterInput): PaymasterParams paymasterAddress: Paymaster 合約地址。 paymasterInput: Paymaster 使用的類型和參數，目 ...

之前文章 zkSync 帳戶抽象 (Account Abstraction) 程式範例說明了 zkSync Era 帳戶抽象的用法，這篇繼續說明另一個 EIP-4337 的擴充功能 － Paymaster。這在 zkSync Era 中也有原生的支持。雖然是帳戶抽象中的擴充功能，實際上並不是只有抽象帳戶才能使用，EOA 帳戶也能使用，是一個獨立的模組。 說明Paymaster 主要的功能是能自訂交易發起人的 Gas 手續費支付方式。以往錢包需要 ETH 才能發送交易，透過 Paymaster 的機制可以解決這問題，可以用各種自訂的方式來代為支付 Gas。例如使用 USDC 等代幣來支付，甚至是免費代為支付。 運作機制是需要先使用智能合約實作 Paymaster，在合約中定義支付的方式，最後在發起的交易 Tx 中指定要使用的 Paymaster。 要實作一個 Paymaster，必須實作的介面如下： 123456789101112131415161718interface IPaymaster { // 主要驗證和支付的邏輯 function validateAndPayF ...

在之前的文章 zkSync 帳戶抽象 (Account Abstraction) 程式範例說明了如何撰寫和部署帳戶抽象合約，也有使用抽象帳戶發起交易的方法。不過專案是用 zksync-cli 建立，使用的是 Ethers.js v5 的版本。這篇文章會說明如何在 Web3.js 的專案中使用，本篇文章使用 Web3.js 4.2.2 版本。 zksync 套件zkSync 提供了官方的套件 zksync2-js 可以用來處理帳戶抽象相關的交易。但是該套件使用 Ethers.js 做為底層來開發，使用這套件等於要同時使用 Ethers.js。我這裡依據官方原始碼改寫了一份 Web3.js 版本的，可直接加入專案使用，就不用和 Ethers.js 混合使用。例如儲存為 eip712-signer.ts： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677 ...

在前一篇文章 zkSync 帳戶抽象 (Account Abstraction) 程式範例說明了如何撰寫和部署帳戶抽象合約，也有使用抽象帳戶發起交易的方法。不過專案是用 zksync-cli 建立，使用的是 Ethers.js v5 的版本。這篇文章會以如何在 Dapp 中，使用現成抽象帳戶的角度來說明。包含 Ethers.js v5 和 v6 的用法，以及實際使用 Metamask 連接使用效果。 zksync 套件zkSync 提供了官方的套件可以用來處理帳戶抽象相關的交易，原先的版本為 zksync-web3，新的版本更名為 zksync2-js。分別對應到 Ethers.js v5 和 v6。 Ethers.js v5：使用 zksync-web3。 Ethers.js v6：使用 zksync2-js。 連接錢包首先要連接錢包，即為後續程式中的 signer 和 provider 的取得方式。 v6私鑰錢包12345import { Provider, Wallet } from 'zksync2-js';const private ...