Gas Optimization
The least expensive Gas transaction contract
1.Element aggregator contract Gas optimization
Contract code optimization.
The main market contract addresses are constantly quantized to reduce the access to contract storage space.
Reduce dependencies on external Libray libraries and reduce cross-contract call function overhead.
Using Assembly Assembly code in core functions is more efficient than Solidity.
Intelligent routing algorithm.
1.The NFTs to be purchased are categorized by market, and the optimal smart contract entry function is selected through the intelligent routing algorithm. Each entry function is optimized to reduce loops, condition judgment, branch prediction, etc. Such as:
buyOneWithETH
batchBuyFromSingleMarketWithETH
batchBuyWithETH
buyOneWithERC20s
batchBuyWithERC20s
2.For native bulk purchase protocols, such as SeaPort and ElementEx, combine a single loop purchase of a single NFT into a single call for bulk purchase NFTs.
2.ElementEx Protocol transaction Protocol Gas optimization
In addition to supporting aggregators, Element also has its own separate trading protocol. ElementEx supports many advanced features and takes advantage of major trading protocols such as Seaport and 0xV4. The team has done a lot of optimization work from the macro architecture layer to the micro code layer. ElementEx achieves the lowest Gas among all transaction protocols.
Split contracts according to ERC721 and ERC1155 asset classes.
The ERC721/1155 STANDARD IS different AND THE TRADING logic is not completely the same. Most markets are processed in a single trading contract. Element Team considers that 98% of mainstream NFTS are ERC721 standard, we make the part of processing ERC721 transaction into independent contracts to achieve the optimal efficiency. ERC1155 also has separate contracts to process transactions.
Split the entry function into buy and sell directions.
Buying an NFT is BuyNow and selling an NFT is AcceptOffer. The logic of the two is different. Most markets process both buy and sell transactions in a single entry function, which is redundant. Through big data analysis, 80% of the transactions are active buying. For example, ElementEx makes buy entry buyERC721 and sell entry sellERC721. This reduces redundant judgment in dealmaking and reduces input parameters.
Split entry functions according to basic and advanced features.
ElementEx contract supports many advanced features such as ETH/WETH hybrid payment, portfolio Offer, real-time royalty, Dutch auction, British Auction, scheduled listing, bulk withdrawal, and Designated Taker purchase. In fact, 90% of users use the most basic BuyNow and are used to paying with ETH. So Element divides buying into two entrance functions: buyERC721 (basic feature purchase entrance: simple logic, low Gas) and buyERC721Ex (advanced feature purchase entrance: complex parameters, complex logic, high Gas). This not only preserves the rich trading contract characteristics, but also maximizes Gas savings.
The order structure is split into buy and sell orders.
Orders in most markets have only one structure, Order, which is distinguished according to orderType. In the above paragraph, there are two entry points for Element buying and selling. Here, we split Order into BuyOrder and SellOrder. Data for advanced features such as collection Offer will only appear in the SellOrder data. This is done in the base order structure, with fewer orderType forks and keeping BuyOrder minimal, resulting in the most common BuyNow operations and no wasted Gas.
Bitwise reuse of fields in the order structure.
ElementEx supports advanced features such as auction and scheduled listing, but these features are not used frequently. So we take something like Uint256 expiry and split it into three more fine-grained fields bitwise, taking up only one EMV to store one 256-bit slot space.
Order status is stored in bits.
In order to prevent repeated execution of orders, most markets generate 256-bit Nonce through KECCAK and then write them into the Mapping slot in the EVM storage area. Here ElementEx introduces 0xProtocol V4, which uses the first 248 bits of 256 bits as buckets and the last 8 bits as offsets. Instead of writing a new 256-bit slot for each order status, the slot is reused until a new slot is enabled for every 256 orders.
Contract code optimization.
Last updated
